Une classe par règle de fichier dans .NET? [fermé]

185

Je suis cette règle mais certains de mes collègues ne sont pas d'accord avec elle et soutiennent que si une classe est plus petite, elle peut être laissée dans le même fichier avec d'autres classes.

Un autre argument que j'entends tout le temps est "Même Microsoft ne fait pas cela, alors pourquoi devrions-nous?"

Quel est le consensus général à ce sujet? Y a-t-il des cas où cela devrait être évité?

Joan Venge
la source

Réponses:

176

Une classe par fichier vous donne également une meilleure idée de ce que chaque archivage change sans regarder les différences du fichier.

marque
la source
4
Plus de classes dans le même fichier améliore la différence entre les classes liées en une seule opération.
Luca
3
Des visionneuses de différences appropriées vous permettent de visualiser toutes les différences d'un commit.
Dykam
44
Je ne suis pas tout à fait sûr de savoir en quoi cette réponse particulière est LA réponse à la ou aux questions du message d'origine. Bien sûr, cela fournit une raison de conserver 1 classe dans un fichier (bien que Luca et Dykam soutiennent de bons points), mais cela ne reflète pas un consensus général ou ne fournit pas de cas où cela devrait être évité.
Robert Davis
4
Les meilleures pratiques n'existent pas, si vous croyez aux meilleures pratiques, comprenez qu'elles ne s'appliquent qu'à un contexte donné. Comme d'autres réponses le soulignent, cette règle créera parfois du code moins maintenable. À mesure que les outils s'améliorent, cette règle devient moins pertinente car il est beaucoup plus facile de trouver des classes et des types dans un projet.
abombss
263

Je déteste quand les gens pensent de manière absolue et disent que vous ne devriez jamais faire ceci ou cela avec quelque chose de subjectif et pointilleux comme celui-ci, comme si nous devions tous nous conformer à l'idée stupide de quelqu'un du bien et du mal. Bottom line: avoir plus d'une classe par fichier est tout à fait acceptable si cela a du sens. Par logique, je veux dire des choses comme:

  1. Rend le code plus facile à digérer et à maintenir
  2. Rend la solution moins ennuyeuse (faire défiler d'innombrables fichiers inutiles) et moins lente
  3. L'équipe de développement est d'accord avec cela en tant que pratique de codage locale

Un très bon exemple de la raison pour laquelle je peux vouloir plusieurs classes par fichier:

Disons que j'ai quelques dizaines de classes d'exceptions personnalisées, chacune étant une ligne 4, je pourrais avoir un fichier séparé pour chacune ou je pourrais regrouper les exceptions et avoir un fichier par groupe. Pour moi, l'approche la plus rationnelle / pragmatique est de les regrouper et de n'avoir que quelques fichiers, car c'est plus efficace en termes de temps / codage (je n'ai pas besoin de faire un clic droit -> Ajouter une classe, renommer, 50 fois) , il maintient la solution moins encombrée et plus performante.

James
la source
92
+1 000. Comprendre la justification des meilleures pratiques et réfléchir à deux fois avant de les enfreindre est une excellente chose. L'adhésion slave est mauvaise.
dsimcha
19
Quelques dizaines de classes d'exceptions personnalisées ? N'est-ce pas là la véritable source du problème? Je ne veux pas simplement être pointilleux ici: je pense que la plupart du temps, les gens veulent combiner des classes dans un seul fichier, c'est parce qu'ils créent inutilement trop de types. (Cela dit, il existe peut-être un cas réel où quelques dizaines de classes d'exceptions personnalisées ont du sens). De nombreuses petites classes sans opération sont normalement le signe d'un problème plus important.
Jeff Sternal
16
Je suis d'accord avec vous pour la plupart. Mais les exceptions sont un cas particulier. Parce qu'un système correctement architecturé doit avoir une gestion des exceptions appropriée pour traiter tous les cas qui génèrent des erreurs légitimes, la plupart des articles sur les meilleures pratiques que j'ai lus soulignent la nécessité de créer des exceptions spécifiques (et parfois vous en avez besoin d'un grand nombre pour couvrir toutes les règles métier sur un grand projet) afin que vous ne finissiez pas par attraper system.exception qui n'est pas du tout une gestion correcte des exceptions.
James
6
Je suis d'accord que vous ne devriez pas suivre servilement une directive sans une bonne raison, mais je ne suis pas d'accord avec le fait que vous devriez avoir plus d'une classe dans un fichier. Pour moi, le fichier doit être nommé d'après la classe et ne pas en contenir plus d'un. Certains langages (java en étant un) notent que la classe est effectivement dans un fichier dont le nom de fichier correspond au nom de la classe. Pour moi, cela facilite la navigation pour les nouveaux arrivants, donc pour cette raison, je pense qu'une classe par fichier est la bonne chose à faire
krystan honore
3
Garder une classe par fichier et synchroniser le nom du fichier et le nom de la classe est une convention, tout comme l'attribution de noms aux variables. Visual Studio est très bien adapté à cette approche. C'est plus facile pour les systèmes de contrôle de source et les développeurs qui sont ajoutés au milieu du projet. Ils rechercheront intuitivement le nom du fichier correspondant au nom de la classe.
Oybek
75
static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
    return (rule.Overhead(useCase) 
            < My.PersonalThresholds.ConformismVsPracticality);
}
Jeremy Bell
la source
4
Existe-t-il une règle comme celle-là dans .NET? J'aurais aussi juste renvoyé le résultat de la déclaration. : O
Joan Venge
50

Je regroupe parfois plus d'une classe dans un fichier si elles sont étroitement couplées et qu'au moins l'une d'entre elles est très petite.

La «meilleure pratique» générale est d'avoir un fichier par classe.

Phil Rykoff
la source
7
Si vous reconnaissez qu'ils sont couplés, pourquoi ne les dissociez-vous pas?
The Matt
39
@The Matt: Cela s'appelle éviter la suringénierie. Si vous avez quelques classes étroitement couplées et que leur découplage ajouterait beaucoup de complexité par rapport à la quantité de flexibilité pratique qu'elles offrent, alors à quoi ça sert?
dsimcha
9
Parfois, j'ai essentiellement des classes de "données" qui ne sont utilisées que par cette classe, donc je mets généralement la classe de données dans le même fichier que l'utilisateur car la datac-lass a généralement peu ou pas de logique elle-même et cela ressemble à un gaspillage pour créer un nouveau fichier pour cela.
Earlz
3
@The Matt: Parfois, il y a des classes d'assistance que je considère comme acceptables pour le couplage. Ils réduisent la complexité d'une partie d'une autre classe mais facilitent toujours un objectif très spécifique à cette classe.
Jordan Parmer
6
@TheMatt: Découpez ceci: msdn.microsoft.com/en-us/library / ... Le couplage entre les modules est mauvais, mais la collaboration entre les classes au sein d'une fonctionnalité logique est inévitable.
Ben Voigt
25

Au-delà des arguments hypothétiques et en se concentrant plutôt sur Windows .NET avec l'IDE Visual Studio et les projets logiciels en croissance, il est logique dans ce contexte d'avoir une classe par fichier.


En général, pour référence visuelle, rien ne vaut une classe par fichier. Vraiment.

Je ne sais pas si Microsoft fait ou ne fait pas la même chose, mais ils ont créé le partialmot - clé pour diviser une classe sur plusieurs fichiers (c'est encore plus grave). Il est souvent utilisé pour diviser le code de concepteur généré automatiquement à partir de votre code personnalisé dans la même classe (mais il est parfois utilisé pour permettre à différents développeurs de travailler sur la classe en même temps via différents fichiers). Microsoft voit donc les avantages de plusieurs fichiers et tout le monde a à l'esprit plusieurs idées d'organisation de fichiers avec .NET.

Pour les classes imbriquées, vous n'avez pas d'autre choix que d'utiliser un fichier, ou au moins les premières parties des classes qu'ils contiennent. Un fichier est nécessaire et bien dans ce cas:

class BicycleWheel {
    class WheelSpoke {
    }
}

Sinon, pourquoi conserveriez-vous plusieurs classes dans un seul fichier? L'argument "parce qu'ils sont petits" ou associés les uns aux autres ne tient pas beaucoup car vos classes seront éventuellement associées à d'autres classes. En fin de compte, vous ne pouvez pas facilement déduire l'organisation des objets dans le fichier en fonction de leur utilisation, d' autant plus que le logiciel continue de croître.

De plus, si vous utilisez des dossiers pour les espaces de noms, vous n'aurez jamais de conflit de nom de fichier de classe. Il est également pratique de localiser une classe par nom de fichier sur le système de fichiers lorsque vous n'êtes pas dans un environnement de développement comme Visual Studio (par exemple si vous souhaitez modifier rapidement une classe avec le Bloc-notes ou quelque chose de rapide / léger ).

Tant de bonnes raisons ...

John K
la source
Merci, qu'entendez-vous par «au moins les premières parties»? Vous voulez dire que vous pouvez également séparer les classes imbriquées?
Joan Venge
1
C'est une référence indirecte au partialmot - clé que j'ai mentionné.
John K
1
Pour mémoire, les classes imbriquées peuvent être partial msdn.microsoft.com/en-us/library/wa80x488(VS.80).aspx J'ai cherché cela par curiosité.
John K
Cela montre seulement que la vue par défaut doit être logique (espace de noms / classe) et non physique (fichiers).
David Schmitt
@DavidSchmitt, c'est à cela que sert l'affichage de classe dans Visual Studio.
Zack
14

Dans la grande majorité des cas, je suis la règle d'une classe par fichier. La seule exception que je fais régulièrement est la définition d'une énumération étroitement couplée à une classe spécifique. Dans ce cas, j'inclurai fréquemment la définition de l'énumération dans le fichier de cette classe.

Greg D
la source
12

Moi aussi, je pense qu'un seul type devrait être inclus dans un seul fichier.

Il y a une exception à cette règle qui doit être mentionnée: avoir deux classes qui ne diffèrent que par un argument générique tel que:

RelayCommand     

et

RelayCommand<T>
Andrei Rinea
la source
Connaissez-vous la solution de contournement pour rendre StyleCop heureux dans ce cas?
George Polevoy
Pas d'accord, il existe une autre convention pour les classes génériques, Foo 1.cs for Foo <T> `et Foo 2.cs for Foo <T, T1>`.
Oybek
@Oybek: Et si j'ai Foo <T>, Foo <U> et Foo <U, T>? Maintenant quoi?
Andrei Rînea
@AndreiRinea Il est impossible d'avoir Foo<T>et Foo<U>dans le même espace de noms. Mais si les espaces de noms diffèrent, ils se trouvent généralement dans des dossiers différents. Ainsi pour Foo<T>et Foo<U>il devrait être Foo 1.cs and for Foo <U, T> `Foo`2.cs. Mais toujours une classe par fichier.
Oybek
Merci pour l'info! :)
Andrei Rînea
8

Vraiment, cela se résume à une préférence personnelle. Tout le monde dira "une classe par fichier", mais nous avons tous nos raisons d'éviter cela dans certaines circonstances. J'avais un grand projet qui comptait environ 300 énumérations différentes. Je ne vais pas avoir 300 fichiers séparés, un pour chaque classe, alors que certaines des énumérations n'étaient qu'à trois états.

De même, pour les personnes qui ne peuvent pas trouver certaines classes si elles ne sont pas toutes dans des fichiers nommés d'après ce qu'elles sont, y a-t-il une raison pour laquelle vous n'utilisez pas Rechercher dans toute la solution? L'utilisation de Find me fait gagner un temps précieux à parcourir l'Explorateur de solutions.

Jason M
la source
Re: find - quand je cherche la définition d'un type, je ne veux pas voir où il est utilisé. En outre, la recherche prend beaucoup plus de temps que le défilement d'une liste de fichiers triés par ordre alphabétique que j'ai probablement déjà divisés (par espace de noms).
Jeff Sternal
1
Je remarque que vous avez indiqué que vous travaillez avec quelque chose que vous avez divisé par espace de noms. Nous n'avons pas tous la chance de toujours travailler avec des projets que nous avons pu gérer, malheureusement.
Jason M
6

Peu importe la légèreté du contenu, je pense qu'une classe / interface / etc. par fichier est essentielle.

Si je travaille sur une grande solution dans Visual Studio, je veux pouvoir voir les fichiers et ne pas avoir à fouiller à l'intérieur pour voir. Même avec des outils de navigation comme ReSharper, je veux une cartographie 1: 1.

Si vous trouvez beaucoup de fichiers source avec peu ou pas de contenu (peut-être en étendant une classe mais en n'y ajoutant rien), vous devriez peut-être repenser votre conception.

Michael
la source
5

Je trouve que regrouper une classe avec sa classe d'usine standard dans le même fichier est très utile.

Robert Davis
la source
5

J'aurais normalement une classe par fichier mais vous devriez normalement utiliser votre discrétion pour voir si le fichier pourrait contenir des classes liées, par exemple en regroupant vos exceptions qui peuvent être réutilisées par vous-même et d'autres développeurs. Dans ce cas, l'utilisateur n'a besoin que d'un seul fichier à inclure plutôt que de plusieurs fichiers.

Le point est donc: la discrétion doit être utilisée !!!

Akapetronics
la source
1
La vraie sagesse, aucune règle de programmation n'est dure et rapide.
ChaosPandion
4

Dans les solutions plus importantes, je pense qu'il est très utile d'avoir une classe par fichier et que le fichier porte le même nom que la classe. Il est beaucoup plus facile de localiser le code dans lequel vous devez travailler.

Chris Clark
la source
Je trouve cet argument moins valable avec des outils comme ReSharper. Je fais CTRL + T et commencez à taper le nom du type que je recherche.
Mark
3
Oui, mais souhaitez-vous que la structure de votre application dépende d'un outil tiers?
magnus
1
@magnus Je ne dis pas que ce n'est pas une raison pour ne pas le faire, mais un argument moins convaincant pour que quelqu'un le fasse.
Mark
4

L'outil StyleCop pour C # a des règles standard qui ne nécessitent pas plus d'une classe de niveau supérieur dans un espace de noms (plus un nombre quelconque d'interfaces, de délégués et d'énumérations dans cet espace de noms).

Dans le cas de deux classes ou plus où la seconde classe et les classes suivantes ne sont utilisées que par la première, celles-ci peuvent et doivent être des classes internes, visibles uniquement par la classe consommatrice.

Steve Gilham
la source
3
Quand vous dites "pas plus d'une classe de premier niveau dans un espace de noms", vous voulez dire dans un namespacebloc, non?
Daniel Pryden
1
Les règles auxquelles il est fait allusion sont SA1403: le document AC # ne peut contenir qu'un seul espace de noms. SA1402: le document AC # ne peut contenir qu'une seule classe au niveau racine à moins que toutes les classes ne soient partielles et soient du même type.
Steve Gilham
4

Parfois une classe par fichier, mais ...

Lorsque plusieurs classes sont strictement liées, plus d'une classe dans le même fichier source est, à mon humble avis, MIEUX que de dédier un court fichier source à chaque classe. La source est plus lisible et compacte (et en utilisant #region, la même source peut être plus structurée qu'auparavant).

Considérez également qu'il est parfois NÉCESSAIRE de répartir la même classe sur différents fichiers (en utilisant partial ), car avoir un fichier source de plus de 20000 lignes n'est pas pratique même avec la RAM dont je dispose (mais c'est une autre question).

Luca
la source
Bien sûr, vous devriez essayer d'éviter d'avoir une classe avec autant de lignes de code. Je dirais que même 1000+ devient trop grand. Je réalise aussi que ce n'est pas toujours possible dans le code hérité.
Peter
Si vous essayez de générer du code source (mon cas est la génération de la liaison C # pour OpenGL à partir de sa spécification, ayant des milliers de points d'entrée), il est difficile de penser une petite classe pour beaucoup de données ...
Luca
3

À l'occasion, je laisserai une petite classe avec une classe plus grande, mais seulement si elles sont très étroitement liées comme un objet et sa classe de collection ou sa fabrique.

Il y a cependant un problème avec cela. Finalement, la petite classe grandit au point où elle devrait être dans son propre fichier, si vous la déplacez vers le nouveau fichier, vous perdez un accès facile à votre historique des révisions.

c'est à dire.

  • lundi je modifie mes classes x et y dans le fichier y.css
  • le mardi, je sépare la classe x dans son propre fichier x.css car il est devenu volumineux
  • mercredi, mon patron veut voir ce que j'ai changé en classe x le lundi donc il regarde l'historique de x.css, seul x.css ne montre pas l'historique avant les changements de mardi.
gingerbreadboy
la source
1
Et si la "petite classe" était quelque chose comme un dérivé d'EventArgs, qui est destiné à transmettre des informations aux destinataires des événements de votre classe? Le code serait-il rendu plus propre ou plus facile à maintenir en déplaçant une telle chose vers un autre fichier? On peut soutenir qu'une telle chose devrait être une classe publique imbriquée, mais celles-ci semblent également être mal vues. En ce qui concerne l'historique des révisions, la classe ne serait-elle pas apparue de nulle part dans le journal des modifications, et ne devrait-elle pas faire un commentaire dans la note de code d'où elle vient?
supercat le
Je classerais cela en tant que very tightly relatedclasse et le laisserais à condition qu'il ne prenne qu'une petite quantité d'espace d'écran et ne soit pas utilisé dans le même but par une autre classe.
gingerbreadboy
3

Est-ce vraiment un problème? :) De très
petites classes, tout comme les énumérations, peuvent être regroupées avec d'autres. Il y a une règle à suivre: ne regrouper que les classes qui ont quelque chose en commun.

En guise de digression - dans l'un de mes projets, j'ai un fichier contenant 150 classes. Le fichier contient 10000 lignes de code. Mais il est généré automatiquement, donc c'est tout à fait acceptable :)

IamDeveloper
la source
1
J'ai un même fichier avec 120 classes et 750 sous-classes avec un demi-million de lignes, il est également généré automatiquement. Le problème est: si je clique dessus, je dois redémarrer car tout s'arrête.
Behrooz
3

L'une des raisons pour lesquelles plusieurs classes associées sont placées dans un fichier est que le pauvre bâtard qui utilise votre API n'a pas à passer une demi-journée à taper une déclaration d'importation standard et le pauvre bâtard qui doit maintenir le code n'a pas à dépenser la moitié. un jour à parcourir le passe-partout de déclaration d'importation. Ma règle de base est que plusieurs classes appartiennent au même fichier si vous utiliseriez presque toujours un grand sous-ensemble d'entre elles en même temps au lieu d'une seule à la fois.

dsimcha
la source
1
Qu'entendez-vous par "passe-partout de déclaration d'importation"? "Utiliser des déclarations"? Mais les classes ne seront-elles pas dans le même espace de noms?
Joan Venge
3
@Joan: Je veux dire devoir importer 15 modules différents mais liés pour accomplir quelque chose de vraiment simple. Peut-être que cela ne s'applique pas spécifiquement à C #. Je ne connais pas vraiment C #, mais dans d'autres langages, c'est un problème assez ennuyeux.
dsimcha
Merci ouais c'est pourquoi j'étais confus.
Joan Venge
2

Je fais cela, mais seulement lorsque les classes sont liées de manière enfant-parent et que les classes enfants sont UNIQUEMENT utilisées par le parent.

CRrésultats
la source
Merci, mais pourquoi ne pas le séparer dans un autre fichier? Juste curieux.
Joan Venge
@henchman l'a dit beaucoup plus éloquemment que moi, en particulier lorsque l'objet enfant est très petit. Il est généralement vrai que la classe enfant n'est que des propriétés avec peut-être seulement un peu de logique
CResults
2

Je m'en tiens généralement à une classe par fichier. Mais je ferai des exceptions pour les groupes de constructions similaires qui sont utilisées à l'échelle du projet. Par exemple:

  • Un EventArgs.cs qui contient des EventArgssous-classes, car il ne s'agit généralement que de 5 à 10 lignes de code chacune, mais elles sont généralement utilisées par plusieurs classes différentes. Alternativement, je pourrais mettre les EventArgsclasses dans le même fichier que la classe qui déclare les événements.
  • Un Delegates.cs qui contient des délégués qui sont utilisés tout au long du projet, car ils ne comportent généralement qu'une ligne chacun. Encore une fois, l'alternative est de les mettre dans le même fichier avec la classe qui les expose / les consomme.
  • Un Enums.cs qui contient les enums utilisés tout au long du projet. (S'il y a un enumqui n'est utilisé que par une classe, je vais généralement le faire privatedans cette classe.)
Daniel Pryden
la source
2

Un autre vote pour une classe par fichier, le fichier portant le même nom que la classe. Pour moi, cela contribue à la maintenabilité à long terme. Je peux facilement parcourir le référentiel et voir quelles classes font partie d'une solution sans avoir à ouvrir le projet ou l'un des fichiers.

Tim Scarborough
la source
2

Je le suis 99% du temps. C'est bien de suivre les normes, mais je crois aussi que la flexibilité a sa place. Parfois, cela semble être une perte de temps stupide de briser les choses. Dans ces moments-là, je me remets de moi-même et j'écris juste mon code.

Mike Pateras
la source
2

Les réponses jusqu'à présent semblent tourner autour des exceptions des gens à la règle, alors voici la mienne: je garde les classes et leurs métadonnées «copains» ensemble lorsque j'utilise le package DataAnnotations dans .NET3.5 SP1. Sinon, ils sont toujours dans des fichiers séparés. Vous savez, la plupart du temps. Sauf quand ils ne le sont pas.

Brant Bobby
la source
2

Je ne fais cela que rarement. Par exemple, s'il existe une énumération ou une structure étroitement liée à la classe mais trop triviale pour être séparée seule.

Ou une classe séparée pour contenir des méthodes d'extension pour cette classe principale.

puffpio
la source
1

One case could be:lorsque vos classes forment conjointement un module / unitqui dessert certaines classes principales comme helper classes, autrement non .

jetez un œil au code source du projet ASP.NET MVC 2.0 . Il suit strictement cette règle

Asad
la source
1

J'aime l'idée de créer des classes plus petites et de m'assurer que la classe ne fait que ce qu'elle est censée faire. Si vous avez plusieurs classes qui contribuent à résoudre un seul problème, il n'y a aucun mal à les regrouper dans le même fichier.

Je ne suivrais pas les pratiques MS car ce ne sont pas les MEILLEURES PRATIQUES!

azamsharp
la source
1

Un autre point que je n'ai vu personne d'autre mentionner est que lorsque vous développez en utilisant la règle d'une classe par fichier, vous pouvez facilement voir ce que cette classe spécifique utilise.

Par exemple: vous pouvez avoir deux classes où une classe utilise Linq et l'autre pas.

Si ces classes étaient dans le même fichier, vous ne seriez pas en mesure de dire sans regarder dans le code quelle classe utilise quoi. Lorsqu'il s'agit d'une classe par fichier, tout ce que vous avez à faire est de regarder en haut du fichier pour voir exactement ce qui est utilisé dans cette classe. Aide si vous migrez un jour vers une nouvelle bibliothèque, etc.

Kieran Oldham
la source
0

Une autre raison pour laquelle une classe par fichier n'a pas été mentionnée dans les réponses publiées jusqu'à présent est qu'une classe par fichier facilite la compréhension de l'impact d'un PR lors d'une révision de code. Cela réduit également les conflits de fusion.

Quand quelqu'un publie un PR pour obtenir des commentaires, je peux consulter la liste des fichiers modifiés et voir immédiatement tout chevauchement avec ce sur quoi je pourrais travailler. En fonction du chevauchement, je pourrais vouloir examiner leur code plus profondément ou lui donner un accord parce que je suis assez convaincu que cela n'affectera pas mes propres changements.

Lorsque deux personnes travaillent dans un fichier multi-classes et que les deux ajoutent une dépendance, il y a de fortes chances que vous obteniez un conflit de fusion dans le usingbloc en haut. La séparation des classes en fichiers sépare les dépendances afin que vous puissiez voir ce que chaque classe utilise et vous n'obtenez pas de conflits comme celui-ci.

Il y a des exceptions à cette règle (interface + implémentation, énumérations, ...) mais c'est un meilleur point de départ que l'inverse qui permet généralement aux développeurs juniors de regrouper toutes sortes de classes non liées dans le même fichier.

Une classe par fichier est une règle claire et non ambiguë non sujette à interprétation.


Les classes liées dans un fichier sont soumises à des préférences personnelles et à une interprétation (comme vous pouvez le voir dans toutes les autres réponses ici pour savoir quand il est acceptable de les utiliser) et est donc une mauvaise règle.

Ian Mercer
la source
-1

Les allers-retours ont été très intéressants et apparemment peu concluants, même si mon impression générale est qu'un mappage 1-1 entre les classes et les fichiers est l'opinion majoritaire, mais avec quelques exceptions personne par personne.

Je suis curieux de savoir si l'une de vos réponses varie selon que vous: (1) développez une application Windows Forms, une application Web, une bibliothèque ou autre; ou (2) en utilisant Visual Studio ou non. En utilisant VS, il semblerait que la règle d'une classe par fichier impliquerait également une classe par projet VS car le consensus dans d'autres threads semble être que les solutions / projets VS devraient être reflétés dans la dénomination et la structure du répertoire / fichier. En effet, mon impression est que le consensus est d'avoir le nom du projet = nom de l'assembly = nom de l'espace de noms (imbriqué), qui serait ensuite reflété dans la dénomination et la structure du répertoire / fichier. Si ce sont les bonnes lignes directrices (ou règles), alors tous ces mécanismes d'organisation apparemment orthogonaux seraient néanmoins synchronisés.

Steve Rehling
la source
-1

Oui pour des raisons de lisibilité, nous devrions avoir un fichier par classe !. Je viens de sauter dans un projet. Je vois de nombreuses classes dans un seul fichier. il est tellement difficile pour un nouveau type de le comprendre. ne devrions-nous pas penser à la maintenabilité? quand on développe un logiciel? plusieurs fois, le développement se poursuivra par d'autres développeurs. Nous avons des espaces de noms pour organiser nos affaires, nous n'avons pas besoin de fichiers pour le faire !.

Ceti
la source
-5

Un élément de code par fichier, oui.

Tout le reste est une faute professionnelle - et, très franchement, un signe de victimisation RAD.

Dès que l'on commence le bon développement logiciel (IoC, design patterns, DDD, TDD, etc ...) et qu'on laisse le terrain de jeu "omg, faisons ça, je n'ai aucune idée de comment, mais je suis payé", on verra ça cette règle compte vraiment, vraiment.

Turing terminé
la source