À quel point / plage un fichier de code est-il trop gros?
Je trouve beaucoup de fichiers de ligne 2-3k, et il ne semble pas vraiment qu'ils devraient être aussi gros.
Quel est un bon critère pour appeler objectivement un fichier de code source "trop gros"?, Existe-t-il une quantité maximale de lignes qu'un fichier de code source devrait avoir?
En tant que modèle idéal, j'utilise les critères suivants (avec une logique similaire à ce que Martin Beckett a suggéré, c'est-à-dire de penser en termes de structure logique et non en termes de lignes de code):
règle 1
Une classe par fichier (en C++: une classe -> un en-tête et un fichier d'implémentation).
règle 2
Sept est considéré comme le nombre d'éléments que notre cerveau peut observer en même temps sans se confondre. Au-dessus de 7, il nous est difficile de garder un aperçu de ce que nous voyons. Par conséquent: chaque classe ne doit pas avoir plus de 7 à 10 méthodes. Une classe qui a plus de 10 méthodes est probablement trop complexe et vous devriez essayer de la diviser. Le fractionnement est une méthode très efficace car chaque fois que vous divisez une classe, vous réduisez la complexité de chaque classe individuelle au moins d'un facteur 2.
règle
Un corps de méthode qui ne tient pas dans un ou deux écrans est trop grand (je suppose qu'une fenêtre écran/éditeur fait environ 50 lignes). Idéalement, vous pouvez voir toute la méthode dans une seule fenêtre. Si ce n'est pas le cas, il suffit de faire défiler un peu vers le haut et vers le bas, sans oublier la partie de la méthode qui est masquée. Donc, si vous devez faire défiler plus d'un écran vers le haut ou vers le bas pour lire tout le corps de la méthode, votre méthode est probablement trop grande et vous pouvez facilement perdre la vue d'ensemble.
Encore une fois, le fractionnement des méthodes à l'aide de méthodes d'aide privées peut réduire la complexité des méthodes très rapidement (à chaque fractionnement, la complexité est au moins réduite de moitié). Si vous introduisez trop de méthodes d'aide privées, vous pouvez envisager de créer une classe distincte pour les collecter (si vous avez plus de méthodes privées que de méthodes publiques, peut-être qu'une deuxième classe se cache dans votre classe principale).
Réunir ces estimations très approximatives:
- Au plus une classe par fichier source.
- Au plus 10 méthodes publiques par classe.
- Au plus 10 méthodes privées par classe.
- Au plus 100 lignes par méthode.
Un fichier source de plus de 2 000 lignes est donc probablement trop volumineux et commence à être trop salissant.
C'est vraiment une estimation très approximative et je ne respecte pas systématiquement ces critères (surtout parce qu'il n'y a pas toujours assez de temps pour faire un refactoring correct). En outre, comme l'a suggéré Martin Beckett, il existe des situations dans lesquelles une classe est une grande collection de méthodes et il n'est pas logique de les diviser de manière artificielle juste pour rendre la classe plus petite.
Quoi qu'il en soit, d'après mon expérience, un fichier commence à devenir illisible lorsque l'un des paramètres ci-dessus n'est pas respecté (par exemple, un corps de méthode de 300 lignes qui s'étend sur six écrans ou un fichier source avec 5000 lignes de code).
Non - pas en termes de lignes de code. Le pilote doit être un regroupement logique. Il ne devrait certainement pas y avoir plusieurs classes dans un grand fichier par exemple
Si vous aviez une classe qui avait légitimement quelques centaines de méthodes (ce qui n'est pas impossible dans la modélisation 3D par exemple), il serait beaucoup moins pratique de diviser cela en fichiers arbitraires. Nous avions l'habitude de le faire lorsque la mémoire était plus rare et les processeurs plus lents - et c'était difficile de chercher constamment la définition de la fonction.
Lorsque le code qu'il contient devient impossible à maintenir. ie: vous ne pouvez pas dire simplement en regardant le code si la méthode/classe/fonction que vous recherchez (et devez éditer/déboguer) est là ou non, et si oui, où il est.
Cependant, votre choix et vos fonctionnalités IDE/Editor influenceront la quantification réelle de cette limite supérieure. pliage de code, liste des fonctions/méthodes et recherche retardera le moment où ce scénario de développement se présente .
Mais quand c'est le cas, il est temps de le diviser.
Voici une vue alternative: vous demandez comment limiter la taille du fichier. Mon opinion est qu'il existe de nombreux facteurs qui rendent les gros fichiers de code très problématiques. Parfois, le fichier de code est énorme, mais son contenu est bien groupé et extrêmement propre, de sorte que la taille ne pose aucun problème significatif. J'ai vu beaucoup de fichiers très lisibles malgré le LOC élevé.
Au lieu de puiser dans la métrique LOC, je préfère penser à utiliser les données d'historique pour comprendre à quelle fréquence le code est cassé dans ces gros fichiers. Habituellement, la raison en est que les développeurs n'ont pas le temps de patienter pour vérifier les autres endroits pertinents dans le même fichier et effectuer le changement avec une mentalité de "solution rapide" sans suffisamment de compréhension.
Le plus grand danger est la présence de code copier-coller. Le codage copier-coller accélère naturellement également la croissance du LOC. Je pense que l'élimination du copier-coller est encore plus importante que de maintenir LOC sous un certain nombre magique. En plus du copier-coller pur, il y a aussi un deuxième danger dans les gros fichiers: les fonctionnalités qui se chevauchent. Plus le fichier est gros, plus vous risquez de réimplémenter un extrait qui se trouve déjà dans une autre section du même fichier.
Ainsi, tant que le ratio de correction de bogues (le ratio de corrections de bogues commises sur toutes les validations) est faible pour les fichiers plus volumineux, la situation est tolérable. S'il vous plaît essayez git log pour cela et parcourez le nombre de commits liés aux erreurs. Ou utilisez un outil qui peut automatiquement l'analyser et le visualiser, par ex. Softagram .
Considérez ceci Metaphor. En ce qui concerne la longueur du code, je pense que nous devrions considérer les éléments suivants:
The Cat in The Hat (50 pp.)
et
Lord of The Rings (1,178 pp.)
Il n'y a rien de mal avec Lord of the Rings. C'est un livre fabuleux. The Cat in the Hat est aussi un excellent livre. Les deux peuvent être compris par un enfant de 5 ans, mais un seul est mieux adapté en raison du contenu.
Pour moi, l'écriture de code devrait avoir du sens pour un enfant de 5 ans chaque fois que nous le pouvons. Cyclomatic Complexity est un concept important que les développeurs doivent considérer lorsqu'ils génèrent du code. Utiliser et créer des bibliothèques pour améliorer autant que possible les fonctionnalités et la réutilisation du code. De cette façon, notre code peut parler plus de volumes que ce que nous voyons écrit.
La plupart d'entre nous n'écrivent pas de code d'assemblage. Mais la racine de notre code est Assembly. Recherche à travers 10000 lignes L'assemblage est plus difficile que 10000 lignes de python, s'il est fait correctement.
Mais certains travaux nécessitent l'écriture de 500 à 1 000 lignes. Notre objectif avec le code devrait être d'écrire 300 lignes de code propre.
En tant que développeurs, nous voulons écrire "Lord of The Rings". Jusqu'à ce que nous obtenions un bug et souhaitions que nous écrivions "Cat in the Hat". Ne faites pas du codage une mesure de l'ego. Faites simplement fonctionner les choses de manière simple.
Les développeurs ne veulent pas documenter le code (j'aime personnellement le code documenté, je ne suis pas si égoïste). N'écrivez donc pas de code que vous seul pouvez comprendre/lire. Écrire Cat in the Hat code.
Nous savons tous que vous êtes J.R.R. Tolken (dans votre tête). N'oubliez pas que vous n'aurez rien à prouver avec un code sans bogue.
Une autre raison de la métaphore.
Ne tuez pas trop le lecteur pour diffuser la richesse. Si vous travaillez avec un groupe de personnes et que toutes doivent changer le même fichier volumineux, vous vous mettrez probablement dans l'enfer de fusion de git.
Tout le monde aime rebaser.
-> Dit personne jamais!
TL; DR Focus sur la lisibilité. Répartissez votre code et votre aide sur plusieurs lignes et fichiers autant que vous le pouvez. Ne jetez pas 8 ou 9 classes dans un seul fichier, cela rend le code difficile à lire et plus difficile à maintenir. Si vous disposez d'un code ou d'une boucle de condition volumineux, envisagez de le remplacer par Lambdas si le langage le prend en charge. Les fonctions utilitaires doivent être considérées comme un excellent moyen d'augmenter la lisibilité du code. Évitez les nids lourds.