Une règle par classe de fichier dans .NET?
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 que d’autres classes.
Un autre argument que j'entends tout le temps est "Même Microsoft ne le fait pas, alors pourquoi devrions-nous?"
Quel est le consensus général à ce sujet? Y a-t-il des cas où cela devrait être évité?
Une classe par fichier vous donne également une meilleure idée de ce que chaque enregistrement change sans regarder les différences du fichier.
Je déteste quand les gens pensent en termes absolus et disent que vous ne devriez jamais faire ceci ou cela avec quelque chose de subjectif et de pointilleux comme celui-ci, comme si nous avions tous besoin de nous conformer à une idée stupide de bien et de mal. Résultat final: avoir plus d'une classe par fichier est tout à fait correct si cela a du sens. Par sens, je veux dire des choses comme:
- Rend le code plus facile à digérer et à maintenir.
- Rend la solution moins agaçante (Défilement d'innombrables fichiers Inutiles) et moins lente
- L’équipe de développement accepte OK. C'est une pratique de codage locale.
Un très bon exemple de la raison pour laquelle je peux vouloir plusieurs classes par fichier:
Supposons que j'ai quelques douzaines de classes d'exceptions personnalisées, chacune étant une ligne 4, je pourrais avoir un fichier séparé pour chacune ou grouper les exceptions et avoir un fichier par groupe. Pour moi, l’approche la plus rationnelle/pragmatique est de les regrouper et de ne disposer que de quelques fichiers, car c’est plus efficace en termes de temps et de code (je n’ai pas à cliquer avec le bouton droit de la souris -> Ajouter une classe, renommer 50 fois) , la solution est moins encombrée et plus performante.
static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
return (rule.Overhead(useCase)
< My.PersonalThresholds.ConformismVsPracticality);
}
Je regroupe parfois plus d'une classe dans un fichier si elles sont étroitement associées et qu'au moins une d'entre elles est très petite.
La «bonne pratique» générale consiste à créer un fichier par classe.
Au-delà d'arguments hypothétiques, nous nous sommes concentrés sur Windows .NET avec Visual Studio IDE et les projets logiciels en croissance, il est donc logique dans ce contexte de disposer d'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 partial mot-clé pour scinder une classe sur plusieurs fichiers. (c'est encore plus grave). Il est souvent utilisé pour séparer le code de concepteur généré automatiquement de votre code personnalisé dans dans la même classe (mais est parfois utilisé pour permettre à différents développeurs de travailler sur la classe en même temps via différents fichiers). Donc, Microsoft voit les avantages de plusieurs fichiers et tout le monde pense à l’organisation de fichiers avec .NET.
Pour les classes imbriquées, vous n'avez pas d'autre choix que d'utiliser un seul fichier, ou du moins les premières parties des classes qu'ils contiennent. Un seul fichier est nécessaire et parfait dans ce cas:
class BicycleWheel {
class WheelSpoke {
}
}
Sinon, pourquoi garder plusieurs classes dans un seul fichier? L'argument "parce qu'ils sont petits" ou associés l'un à l'autre ne correspond pas retenez beaucoup d'eau car vos classes seront éventuellement associées à d'autres classes. En fin de compte, vous ne pouvez pas facilement déduire l'organisation d'objets dans le fichier en fonction de leur utilisation , d'autant plus que les logiciels continuent de croître.
De plus, si vous utilisez des dossiers pour les espaces de noms , vous ne rencontrerez jamais de conflit de classe. Il est également pratique de localiser une classe par nom de fichier sur le système de fichiers lorsque vous ne vous trouvez pas dans un environnement de développement tel que Visual Studio (par exemple si vous voulez éditer rapidement une classe avec Notepad ou quelque chose de rapide/léger ).
Tant de bonnes raisons ...
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 liée à une classe spécifique. Dans ce cas, j'inclurai fréquemment la définition de l'énum dans le fichier de cette classe.
Moi aussi, je pense qu'il devrait y avoir un type 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>
Vraiment, cela revient à une préférence personnelle. Tout le monde dira "une classe par fichier", mais nous avons tous nos raisons pour éviter cela dans certaines circonstances. J'avais un grand projet qui avait environ 300 enums différents. En aucun cas, je vais avoir 300 fichiers séparés, un pour chaque classe, lorsque certains des énumérations étaient tri-états.
De même, pour les personnes qui ne peuvent pas trouver certaines classes si elles ne figurent pas toutes dans des fichiers nommés d'après ce qu'elles sont, existe-t-il une raison pour laquelle vous n'utilisez pas Rechercher dans la solution complète? Utiliser la recherche me fait gagner un temps précieux en parcourant l'Explorateur de solutions.
Peu importe la légèreté du contenu, je pense qu’une classe/interface/etc. par fichier est essentielle.
Si je travaille sur une grosse 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 souhaite une cartographie 1: 1.
Si vous trouvez beaucoup de fichiers source avec peu ou pas de contenu (peut-être étendre une classe sans rien y ajouter), vous devriez peut-être repenser votre conception.
J'aurais normalement une classe par fichier mais vous devriez normalement utiliser votre discrétion pour voir si le fichier peut contenir des classes apparentées, par exemple regrouper vos exceptions qui peuvent être réutilisées par vous-même et par d'autres développeurs. Dans ce cas, l'utilisateur n'a besoin d'inclure qu'un seul fichier plutôt que plusieurs fichiers.
Donc, le point est: discrétion devrait être utilisé !!!
Je trouve qu’il est très utile de regrouper une classe avec sa classe standard.
Dans les solutions plus grandes, 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.
L'outil StyleCop pour C # a des règles standard qui n'exigent pas plus d'une classe de niveau supérieur dans un espace-noms (plus un nombre quelconque d'interfaces, de délégués et d'énums dans cet espace-noms).
Dans le cas de deux classes ou plus où la deuxième classe et les suivantes ne sont utilisées que par la première, celles-ci pourraient et devraient être des classes internes, visibles uniquement par la classe consommatrice.
Parfois, une classe par fichier, mais...
Lorsque plusieurs classes sont étroitement liées, plusieurs classes du même fichier source sont, à mon humble avis, MEILLEUR que de dédier un fichier source court à chaque classe. La source est plus lisible et compacte (et en utilisant #region, la même source peut être plus structurée qu’avant).
Pensez aussi que parfois il est N&EACUTE;CESSAIRE de répartir la même classe sur différents fichiers (avec partial), car avoir un fichier source de 20000+ lignes n'est pas pratique même avec la RAM J'ai disponible (mais c'est une autre question).
Est-ce vraiment un problème? :)
Les classes vraiment petites, tout comme les enums, peuvent être assemblées avec d’autres. Il y a une règle à suivre: ne créez que des classes qui ont quelque chose en commun.
En guise de digression - dans un de mes projets, j'ai un fichier contenant 150 classes. Le fichier contient 10000 lignes de code. Mais c'est généré automatiquement alors c'est tout à fait acceptable :)
À l'occasion, je laisserai une petite classe avec une classe plus nombreuse, mais seulement si elles sont très étroitement liées, comme un objet et que c'est une classe de collection ou une usine.
Il y a cependant un problème avec cela. Finalement, la petite classe grandit au point où elle devrait se trouver dans son propre fichier. Si vous la déplacez dans le nouveau fichier, vous perdez facilement l'accès à votre historique de révision.
c'est à dire.
- le 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 parce qu'il a grandi
- mercredi, mon patron veut voir ce que j'ai changé en classe x lundi. Il examine donc l'historique de x.css. Seul x.css n'affiche pas l'historique avant les changements du mardi.
Une des raisons pour mettre plusieurs classes related dans un fichier est afin que le pauvre bâtard qui utilise votre API n’ait pas à passer une demi-journée à taper la déclaration d’importation warmplate et le pauvre bâtard qui doit gérer le code ne le fait pas. passer une demi-journée à parcourir le passe-passe de la déclaration d'importation. Ma règle empirique est que plusieurs classes appartiennent au même fichier si vous en utilisiez presque toujours un grand sous-ensemble en même temps au lieu d'un seul à la fois.
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 ni aucun des fichiers.
Je le suis 99% du temps. C'est bien de suivre les normes, mais je pense aussi que la flexibilité a sa place. Parfois, il semble tout simplement comme une perte de temps idiote de séparer les choses. Dans ces moments, je me ressaisis et écris mon code.
Je le fais, mais uniquement lorsque les classes sont liées de manière enfant-parent et que les classes enfant sont UNIQUEMENT utilisées par le parent.
Je ne le fais 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.
Jusqu'ici, les réponses semblent tourner autour des exceptions des personnes à la règle, alors voici la mienne: je garde les classes et leurs métadonnées 'classes d'amis' 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.
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 supposée faire. Si plusieurs classes contribuent à résoudre un seul problème, il n’ya aucun mal à les regrouper dans le même fichier.
Je ne suivrais pas les pratiques de la SEP, car elles ne sont pas les MEILLEURES PRATIQUES!
Je m'en tiens habituellement à une classe par fichier. Mais je ferai des exceptions pour les groupes de constructions similaires qui sont utilisés dans l’ensemble du projet. Par exemple:
- Un EventArgs.cs contenant toutes les sous-classes
EventArgs, car elles ne représentent généralement que 5 à 10 lignes de code, mais elles sont généralement utilisées par plusieurs classes différentes. Alternativement, je pourrais mettre les classesEventArgsdans le même fichier que la classe qui déclare les événements. - Delegates.cs qui contient des délégués utilisés tout au long du projet, car ils ne comportent généralement qu’une ligne. Là encore, l’alternative consiste à les placer dans le même fichier que la classe qui les expose/les consomme.
- Un Enums.cs contenant
enums utilisé tout au long du projet. (S'il existe uneenumutilisée par une seule classe, elle sera généralementprivatedans cette classe.)
One case could be: lorsque vos classes forment ensemble un module / unit qui sert certaines classes principaleslike helper classes, autrement sages non.
jetez un oeil à ASP.NET MVC 2.0 code source du projet. Il suit strictement cette règle
Le va-et-vient a été très intéressant et apparemment peu concluant, bien que mon impression générale soit qu'un mappage 1-1 entre classes et fichiers constitue l'opinion de la majorité, bien qu'avec quelques exceptions individuelles.
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 "une classe par fichier" impliquerait également une classe par projet de VS, car le consensus dans les autres threads semble être que les solutions/projets de VS doivent être reflétés dans la structure et le nom du répertoire/fichier. En effet, mon impression est que le consensus est d’avoir le nom du projet = nom de l’assemblée = nom de l’espace de noms (imbriqué), qui seraient tous reflétés dans la structure et le nom des fichiers/répertoires. Si ce sont les bonnes règles (ou règles), alors tous ces mécanismes d'organisation apparemment orthogonaux seraient néanmoins maintenus synchronisés.
Oui, pour des raisons de lisibilité, nous devrions avoir un fichier par classe! . Nous avons juste sauté dans un projet. Je vois beaucoup de classes dans un fichier. il est donc 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 sera poursuivi par d'autres développeurs . Nous avons des espaces de noms pour organiser nos fichiers, nous n'avons pas besoin de fichiers pour le faire!.