Longueur et largeurs de ligne «recommandées» [fermé]

J'étais curieux de savoir si quelqu'un connaissait une recommandation d'une source fiable pour le nombre maximum de lignes de code pour un fichier donné. Par exemple, Google Closure Linter recommande que chaque ligne ne dépasse pas 80 caractères.

Un fichier doit être suffisamment court pour que vous puissiez trouver n'importe quelle fonction ou méthode sans faire défiler plusieurs fois d'avant en arrière, sans avoir à vous souvenir d'une chaîne de recherche. La métrique que j'utilise est le temps que je passe à rechercher du code dans un fichier par rapport à sa lecture. Si cela devient visible, il est temps de repartitionner le fichier ou la classe.

Une bonne taille pour un bloc de code de base est suffisamment courte, à la fois en largeur et en hauteur, pour que vous puissiez en projeter les tripes lors d'une révision de code de groupe et que tout soit adapté sans que la police soit si petite que le gars à l'arrière de la salle de conférence ne peut pas le lire. Cette taille est également utile si vous êtes appelé pour expliquer du code alors que tout ce que vous avez avec vous est un appareil mobile ou une tablette.

Il n'y a rien de tel, et s'il y en avait, cela dépendrait fortement du langage que vous utilisiez (faire la même chose dans l'assembleur contre C # ou Java par exemple).

Pour les langues de niveau supérieur, vous pouvez voir cette discussion SO. Pour Java / C #, 10-20 lignes par méthode est ce que Bob Martin recommande au maximum. Il n'y a pas de discussion concernant les fichiers, car ils ne sont pas pertinents et dépendent de ce que la classe est censée faire.

En ce qui concerne la limite de 80 caractères par ligne - c'est un retour aux jours des cartes perforées. Cela dit, lorsque les lignes s'allongent trop, la lisibilité en souffre.

Les longueurs de fichier et de ligne sont des mesures des effets secondaires de la complexité et, en tant que telles, sont très variables. Ce que vous devez viser, c'est du code sans complexité inutile, pas un certain nombre de lignes maximum.

Les fichiers longs ont tendance à indiquer que les méthodes, sous-routines ou classes sont trop complexes (faire trop de choses, pas suffisamment factorisées, etc.)

Les longues lignes ont tendance à indiquer que les expressions sont trop complexes.

Ce sont des odeurs qui indiquent un problème de code potentiel, pas des mesures cibles bien définies.

La longueur de la ligne doit être telle que vous n'ayez pas à faire défiler l'écran pour voir la ligne entière. Cela dépend de la taille et de la résolution du moniteur.

Les méthodes et les fonctions sont optimales si elles peuvent s'adapter à un seul écran.

Les fichiers ne devraient pas être trop longs. Les meilleurs sont des fichiers courts, où il est facile de comprendre la classe et l'implémentation.
Une fois, j'ai travaillé sur un projet qui avait un fichier de 10 klines. C'était comme lire un livre très complexe. Dois-je indiquer le nombre de problèmes causés par la mise en œuvre?

80 caractères!

Je me souviens que j'avais l'habitude de voir les fichiers de code source pour les programmes de facturation d'environ 80 pages et plus quand j'ai fait COBOL. Bien sûr, je ne vois pas que cela est proche de la pratique courante, mais 80 caractères est tout aussi ridicule.

Du point de vue de la taille d'une classe, si vous essayez d'appliquer cette suggestion à une classe client typique qui a environ 80 propriétés et 20 méthodes environ, vous devrez diviser la classe en plusieurs autres et rendre le code très compliqué.

J'essaie de garder les classes et les méthodes courtes, mais ne vous inquiétez pas trop de la longueur de la ligne. En ces jours d'écrans larges et de longs identifiants, je pense que quatre-vingts caractères, c'est beaucoup trop peu. Il faut du travail pour briser les instructions afin qu'elles soient faciles à lire, et avec une limite de quatre-vingts caractères, cela arrive assez fréquemment. Je pense qu'environ 120 ou 130 colonnes par ligne est plus raisonnable.