Guides de codage: Comment divisez-vous vos gros fichiers source?

Question

Le projet sur lequel je travaille vient de contenir 4200 lignes dans le fichier principal C #, ce qui oblige IntelliSense à prendre quelques secondes (parfois jusqu'à six ou plus) pour que Visual Studio se verrouille. Je me demande comment les autres divisent leurs dossiers et s’il existe un consensus.

J'ai essayé de rechercher certains guides et trouvé le guide C ++ de Google , mais je ne pouvais rien voir de la sémantique telle que la taille des fonctions et la taille des fichiers; c'est peut-être là - je ne l'ai pas regardé depuis un moment.

Alors, comment divisez-vous vos fichiers? Groupez-vous vos méthodes par les fonctions qu'elles remplissent? Par types (gestionnaires d'événements, privés / publics)? Et à quelle taille limite divisez-vous les fonctions?

Pour clarifier, l'application en question gère les données - son interface est donc une grille à gros cul, et tout tourne autour de la grille. Il y a quelques formes de dialogues pour la gestion, mais tout tourne autour des données. La raison de sa taille est qu’il ya beaucoup de vérification d’erreurs, de gestion des événements, ainsi que la grille configurée en tant que maître-détail avec trois grilles supplémentaires pour chaque ligne (mais celles-ci se développent sur la ligne principale). J'espère que cela aidera à clarifier mon propos.

Answer 1

Je pense que votre problème se résume au terme que vous utilisez: "Fichier principal C #".

À moins que vous ne vouliez dire main (comme dans la méthode main ()), il n’ya pas de place pour ce concept.

Si vous avez une classe utilitaire fourre-tout ou d'autres méthodes courantes, vous devez les diviser en plusieurs parties fonctionnelles similaires.

Généralement, mes fichiers ne sont que des mappages de classes individuels.

Parfois, les classes très liées se trouvent dans le même fichier.

Si votre fichier est trop volumineux, cela signifie que votre classe est trop volumineuse et trop générale.

J'essaie de garder mes méthodes à un demi-écran ou moins. (Quand il s’agit de code, j’écris à partir de rien, il ne contient généralement que 12 lignes, mais dernièrement, j’ai travaillé dans le code existant d’autres développeurs et ai dû refactoriser 100 fonctions de ligne ...)

Parfois, il s'agit d'un écran, mais celui-ci devient très volumineux.

EDIT:

Pour répondre à votre question de taille limite au sujet des fonctions - pour moi, il s’agit moins de la taille (bien que ce soit un bon indicateur d’un problème) et plus du fait de ne faire qu’une chose et de garder chacune SIMPLE.

Answer 2

Dans le livre classique, Programmation structurée " Dijkstra a écrit une fois une section intitulée: "De notre incapacité à faire beaucoup". Son point était simple. Les humains ne sont pas très intelligents. Nous ne pouvons pas jongler avec plus de quelques concepts dans notre esprit à la fois.

Il est très important de limiter la taille de vos classes et méthodes. Lorsqu'une méthode dépasse une douzaine de lignes, elle doit être séparée. Lorsqu'une classe dépasse 200 lignes, elle doit être séparée. C’est le seul moyen de garder le code bien organisé et gérable. Je programme depuis près de 40 ans et, année après année, je me rends compte à quel point le mot "petit" est important. est lors de l'écriture de logiciels.

En ce qui concerne comment vous faites cela, il s'agit d'un sujet très vaste qui a été écrit à de nombreuses reprises. Tout est question de gestion de la dépendance, de masquage d'informations et de conception orientée objet en général. Voici une liste de lecture.

• Nettoyer le code
• SOLID
• Principes, modèles et pratiques Agile en C #

Answer 3

Divisez vos types là où il est naturel de les séparer - mais faites attention aux types qui en font trop. À environ 500 lignes (de Java ou C #), je m'inquiète. À environ 1000 lignes, je commence à me demander si le type doit être scindé ... mais parfois il ne peut pas / ne devrait pas l'être.

En ce qui concerne les méthodes: je n'aime pas quand je ne peux pas voir toute la méthode à l'écran à la fois. Évidemment, cela dépend de la taille du moniteur, etc., mais c'est une règle raisonnable. Je préfère cependant qu'ils soient plus courts. Là encore, il existe des exceptions: il est très difficile de démêler certaines logiques, en particulier s’il existe de nombreuses variables locales qui ne veulent pas naturellement être encapsulées ensemble.

Parfois, il est logique qu'un seul type ait beaucoup de méthodes, telles que System.Linq.Enumerable , mais des classes partielles peuvent vous aider dans de tels cas, si vous pouvez diviser le type en groupes logiques cas de Enumerable , regrouper par agrégation / définir des opérations / filtrer, etc. semblerait naturel). De tels cas sont cependant rares dans mon expérience.

Answer 4

Le livre de Martin Fowler, Refactoring , est un bon point de départ pour cela. Il explique comment identifier les "odeurs de code". et comment refactoriser votre code pour corriger ces "odeurs". Le résultat naturel (bien que ce ne soit pas l'objectif principal) est que vous vous retrouviez avec des classes plus petites et plus faciles à gérer.

MODIFIER

À la lumière de votre modification, j'ai toujours insisté sur le fait que les bonnes pratiques de codage pour le code d’arrière-plan sont les mêmes dans le niveau présentation. Certains modèles très utiles à prendre en compte pour les refactorisations d’UI sont les suivants: commande, stratégie, spécification et état.

En bref, votre vue ne doit contenir que du code permettant de gérer les événements et d’attribuer des valeurs. Toute logique doit être séparée dans une autre classe. Une fois que vous faites cela, vous constaterez qu'il devient plus évident de pouvoir refactoriser. Les grilles rendent cette tâche un peu plus difficile, car elles facilitent trop la division de votre état de présentation entre la logique de présentation et la vue. Toutefois, avec un peu de travail, vous pouvez utiliser une indirection pour minimiser la douleur engendrée par cette opération. .

Answer 5

Ne codez pas de manière procédurale et vous ne vous retrouverez pas avec 4 200 lignes dans un fichier.

En C #, il est judicieux de respecter les SOLID . principes de conception orientés objet. Chaque classe devrait avoir une et une seule raison de changer. La méthode principale devrait simplement lancer le point de départ de l’application (et configurer votre conteneur d’injection de dépendance, si vous utilisez quelque chose comme StructureMap).

Je n'ai généralement pas de fichiers contenant plus de 200 lignes de code, et je les préfère s'ils ont moins de 100.

Answer 6

Il n’existe pas de règles strictes, mais il est généralement admis que plus de fonctions courtes sont meilleures qu’une seule grande fonction et que plus de classes plus petites valent mieux qu’une grande classe.

Les fonctions de plus de 40 lignes ou plus devraient vous amener à réfléchir à la manière de les séparer. Regardez en particulier les boucles imbriquées, qui sont source de confusion et qui sont souvent faciles à traduire en appels de fonction avec de beaux noms descriptifs.

Je coupe les cours quand je sens qu’ils font plus d’une chose, comme mélanger présentation et logique. Une grande classe est moins un problème qu'une grande méthode, tant que la classe fait 1 chose.

Le consensus dans les guides de style que j’ai vu est de regrouper les méthodes par accès, avec les constructeurs et les méthodes publiques en haut. Tout ce qui est cohérent est génial.

Vous devriez lire le style C # et la refactorisation pour bien comprendre les problèmes que vous résolvez.

il y a un certain nombre de est un excellent livre qui contient des astuces pour la réécriture du code afin que le comportement soit préservé, mais que le code soit plus clair et plus facile à utiliser.

Eléments du style C # est un bon guide de style C # pour arbre mort, et ce article de blog contient un certain nombre de liens vers de bons guides de style en ligne.

Enfin, envisagez d'utiliser FxCop et StyleCop . Cela n'aidera pas les questions que vous avez posées, mais pourra détecter d'autres problèmes stylistiques avec votre code. Puisque tu as plongé ton orteil dans l’eau, tu pourrais tout aussi bien y aller.

C'est beaucoup, mais le développement des goûts, du style et de la clarté constitue une différence majeure entre les bons et les mauvais développeurs.

Answer 7

Chaque classe doit faire une petite chose et bien la faire. Votre classe est-elle un formulaire? Ensuite, il ne devrait contenir AUCUNE logique métier.

Représente-t-il un concept unique, comme un utilisateur ou un état? Ensuite, il ne devrait pas y avoir de dessin, charge / sauvegarde, etc ...

Chaque programmeur passe par des étapes et des niveaux. Vous reconnaissez un problème avec votre niveau actuel et vous êtes prêt à aborder le prochain.

D'après ce que vous avez dit, votre niveau actuel semble "résoudre un problème", probablement à l'aide d'un code de procédure, et vous devez commencer à chercher de nouvelles façons de l'aborder.

Je vous recommande de vous renseigner sur la manière de vraiment concevoir le logiciel OO. Vous avez probablement entendu beaucoup de théories qui n'ont aucun sens. La raison pour laquelle ils ne le font pas, c'est qu'ils ne s'appliquent pas à la façon dont vous programmez actuellement.

Laisse-moi trouver un bon post ... Regarde par ceux-ci pour commencer:

comment coder de manière procédurale -habits

sont-il-toutes-règles-pour-oop

héritage orienté-objet-v -composition-v-interfaces

Certains articles vous renverront à de bons livres de conception OO. Un "Refactoring" Ce livre est probablement l’un des meilleurs endroits où vous pourriez commencer.

Vous en êtes à un bon point pour le moment, mais vous ne croyez pas à quel point vous devez aller. J'espère que cela vous enthousiasme car certains de ces programmes dans votre proche avenir comptent parmi les meilleurs programmes "Expériences d'apprentissage". vous aurez jamais.

Bonne chance.

Answer 8

Vous pouvez rechercher de petites choses à changer et chaque fois lentement.

• Toutes les méthodes utilisées dans cette classe sont-elles uniquement? Recherchez des méthodes de support, telles que la validation, la manipulation de chaînes, pouvant être déplacées vers des classes helper / util.

• Utilisez-vous des sections #region? Les regroupements logiques de méthodes apparentées dans une # région se prêtent souvent à être divisés en classes séparées.

• La classe est-elle un formulaire? Pensez à utiliser les contrôles utilisateur pour les contrôles de formulaire ou les groupes de contrôles de formulaire.

Parfois, les grandes classes évoluent avec le temps en raison du nombre important de développeurs qui apportent des solutions rapides / nouvelles fonctionnalités sans prendre en compte la conception globale. Revenez sur certains des liens de théorie du design que d'autres ont fournis ici et envisagez un soutien continu pour les appliquer, tels que des révisions de code et des ateliers d'équipe pour examiner le design.

Answer 9

Eh bien, j'ai peur de dire que vous avez peut-être un problème plus important qu'un temps de chargement lent. Vous allez rencontrer des problèmes de code étroitement couplé et de problèmes de maintenabilité / lisibilité.

Il existe de très bonnes raisons de scinder les fichiers de classe en fichiers plus petits (et également de déplacer des fichiers vers différents projets / assemblages).

Réfléchissez à l’objectif visé par votre classe. Chaque fichier ne devrait avoir qu'un seul but. Si son objectif est trop général, par exemple, "Contenir la logique du panier", alors vous vous dirigez dans la mauvaise direction.

Par ailleurs, comme indiqué précédemment, le terme que vous utilisez est: "Fichier principal C #". ça sent juste que vous avez un état d'esprit très procédural. Je vous conseillerais de vous arrêter, de prendre du recul et de lire rapidement certains des sujets suivants:

• Principes généraux de la POO
• Conception axée sur le domaine
• Test unitaire
• Conteneurs IoC

Bonne chance dans vos recherches.

Answer 10

Utilisez les classes partielles. En gros, vous pouvez diviser une classe en plusieurs fichiers.

Answer 11

Peut-être que le PO peut répondre: votre projet utilise-t-il la programmation orientée objet? Le fait que vous utilisiez le mot "fichier". suggère que ce n'est pas le cas.

Tant que vous ne comprenez pas l'orientation des objets, il n'y a aucun espoir d'améliorer votre code de manière importante. Vous feriez mieux de ne pas diviser le fichier du tout, attendez qu’il devienne insupportablement lent et bogué, puis, au lieu de le supporter, allez apprendre OO.

Answer 12

L’analyseur Intellisense dans Visual Studio 2008 semble être beaucoup plus rapide que celui de 2005 (je sais qu’il a beaucoup travaillé dans ce domaine), donc vous devriez certainement envisager de scinder le fichier à un moment donné, comme d’autres. Comme mentionné précédemment, Visual Studio 2008 peut résoudre votre problème de performance immédiat. Je l'ai utilisé pour ouvrir un fichier Linq to SQL de plus de 100 000 lignes sans trop de problèmes.

Answer 13

Divisez le code pour que chaque classe / fichier / fonction / etc. ne fait qu'une chose & # 8482 ;. Le le principe de responsabilité unique constitue un bon guide pour la division de fonctionnalités en classes.

De nos jours, les classes les plus importantes que j'écris ont environ 200 lignes et les méthodes utilisent généralement entre 1 et 10 lignes.

Answer 14

Si vous avez des régions de code dans une classe, une méthode simple consiste à utiliser le mot-clé partial et à décomposer cette définition de la classe dans ce fichier. Je le fais généralement pour les grandes classes.

La convention que j'utilise est d'avoir le ClassName_RegionName.cs. Par exemple, si je souhaite séparer une classe qui gère le schéma pour une connexion à une base de données et que j'appelle la classe DatabaseConnection, je crée un fichier appelé DatabaseConnection.cs pour la classe principale, puis DatabaseConnection_Schema.cs pour la fonctionnalité de schéma. / p>

Certaines classes doivent simplement être grandes. Ce n'est pas mauvais design; ils sont juste lourds en implémentation.