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

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é?

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

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.

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 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.

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 ...

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.

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>

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.

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.

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

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 !!!

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.

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.

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).

À 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.

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 :)

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.

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.

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.)

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.

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.

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.

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.

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

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!

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.

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.

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.

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 !.

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.