Les classes, énumérations et autres entités doivent-elles être placées dans des fichiers séparés?

Le chef d'équipe \ architecte de mon entreprise soutient qu'un projet à grande échelle est plus facile à comprendre si les "entités connectées par la logique" sont placées dans un fichier .cs.

Je cite:

• "Toute la structure de la logique et de l'interface et de la classe peut être vue en un seul endroit, c'est un argument qui ne peut pas être réfuté. Pour voir la même chose mais avec un tas de fichiers, vous devez utiliser les outils, classe diagramme, R # pour la navigation, etc. "

• "En suivant la pauvre théorie, je pourrais crier qu'une armée de fichiers séparés est cool, mais quand il s'agit de modifier le code existant, surtout si vous n'étiez pas un écrivain de ce code, il est très difficile de comprendre beaucoup de fichiers dispersés. Donc sur les forums, vous pouvez écrire "un enum- un fichier", mais en pratique cette approche ne doit jamais être utilisée "

• "... Quant à la séparation de la base de code entre les développeurs, de nos jours ce n'est pas un problème d'éditer simultanément le même fichier. La fusion n'est pas un problème."

J'ai entendu et lu à plusieurs reprises que nous devons créer un fichier .cs par énumération, classe, etc., et c'est la meilleure pratique.

Mais je ne peux pas le convaincre. Il dit qu'il ne fait confiance à aucun programmeur bien connu comme Jon Skeet. À propos, voici l'opinion de Skeet sur ce sujet: Où est le meilleur endroit pour localiser les types d'énumération?

Qu'est-ce que tu penses? Y a-t-il un vrai problème? Ou est-ce une question de goût et devrait être réglementé par la norme de codage de l'organisation?

Il y a quelques défauts dans l'argument de votre chef d'équipe:

1. Les classes et énumérations bien conçues sont destinées à être utilisées n'importe où dans votre projet, pas seulement là où elles peuvent avoir un sens logique.

2. Les classes et énumérations correctement documentées avec des commentaires XML sont très auto-descriptives, simplement en survolant l'élément qui y fait référence.

3. Vous pouvez toujours obtenir une définition de classe ou ENUM par un clic droit sur la référence et en sélectionnant « Aller à la définition, » donc il ne devrait vraiment pas d' importance où vous le mettez.

4. Assembler des objets de façon «logique» est arbitraire (c'est-à-dire que vous devez penser à ce que signifie «logique». Je préfère consacrer ces cycles d'horloge à la programmation réelle).

La mise en place de chaque définition d'objet dans son propre fichier crée une attente uniforme et disciplinée d'organisation et de structure, et ne soulève pas de questions comme «pourquoi est-ce ici? C'est une très bonne chose à avoir.

Si deux ou plusieurs objets sont logiquement liés, placez-les simplement dans leur propre dossier dans l'Explorateur de projets.

Très probablement, le chef d'équipe s'est coupé les dents à une époque antérieure lorsque faire un clic droit et choisir «aller à la définition» n'était pas une option. Je sais que lorsque je suis en mode de développement à forte pointe, je vais développer des fichiers de classe assez massifs jusqu'à ce que je laisse Resharper le réparer pour moi.

Dans tous les cas, si vous voulez diriger l'équipe vers la tâche, demandez-lui pourquoi ces classes et énumérations ne sont pas des classes et énumérations enfants - aucune raison de les déclarer en tant qu'entités indépendantes si elles sont vraiment des entités dépendantes. Cela pourrait l'aider à réfléchir un peu à la fatwa.