Existe-t-il un nombre optimal de lignes de code par fonction? [fermé]

Les fonctions ne sont pas seulement utilisées pour minimiser la duplication de code - elles sont également utilisées pour diviser une fonction longue en plus petites pour augmenter la lisibilité, ainsi que pour rendre le code auto-commenté. Pourtant, ce gain n'est pas directement inversement proportionnel au nombre de LOC par fonction ou méthode; sinon, nous aurions des tonnes de fonctions, qui ne contiennent qu'une ou deux lignes de code.

Cela m'amène à me demander: existe-t-il un nombre optimal de LOC par fonction? Si c'est le cas, qu'est-ce que c'est et est-ce qu'il s'écarte entre les langues?

Au lieu du nombre de lignes, le critère que j'utiliserais est que chaque fonction ne fasse qu'une seule chose et le fait bien.

Une ancienne règle empirique est qu'une fonction doit être entièrement visible à l'écran, sans avoir besoin de faire défiler.

L'idée de base est que, si vous ne pouvez pas regarder la fonction entière à la fois, la fonction est trop complexe et vous devez la diviser en morceaux plus basiques.

Bien que cette règle soit très pratique et utile, la règle formelle est que vous ne devez conserver qu'une seule étape logique dans une fonction. Une fonction ne fait qu'un travail élémentaire, si vous pouvez diviser le travail en plusieurs morceaux élémentaires, la fonction doit être divisée.

Il n'y en a pas.

Les écrans deviennent plus grands, les tailles de police plus petites. Les règles de base ne fonctionnent pas si bien lorsque les gens ont des pouces de tailles différentes.

Soyez concis. Si votre fonction fait plusieurs choses, c'est probablement une bonne idée de la diviser en plus petites.

Smalltalk a une façon légèrement inhabituelle de réduire la taille des méthodes. Lorsque vous écrivez du code, vous l'écrivez dans un widget appelé navigateur. Un navigateur a deux parties principales, divisées horizontalement. Votre code va dans la moitié inférieure.

Par défaut, un navigateur n'est pas très gros. Vous pouvez insérer 5 ou 6 lignes avant de devoir commencer le défilement. Le défilement, bien sûr, est légèrement irritant.

Ainsi, dans Smalltalk, l'environnement "vous encourage" à écrire des méthodes courtes, d'au plus environ 6 lignes de longueur. (C'est généralement beaucoup; Smalltalk est un langage assez laconique.)

Le nombre idéal de lignes de code dans une méthode est variable. Fondamentalement, vous voulez seulement écrire juste assez de code pour faire ce qui doit être fait dans le contexte de la définition de la fonction. Je pense à cela comme une sorte de principe de responsabilité unique , appliqué uniquement à une méthode plutôt qu'à une classe.

Lorsqu'une méthode a beaucoup de logique et un certain nombre d'étapes à effectuer, il est logique de diviser la méthode en plusieurs étapes distinctes. Chacune de ces étapes serait extraite dans de nouvelles méthodes selon les besoins.

"Sinon, nous aurions des tonnes de fonctions, qui ne contiennent qu'une ou deux lignes de code."

Moins chaque méthode est efficace, plus elle est facile à définir et plus simple à comprendre et à gérer. Il n'y a rien de mal à avoir des centaines de méthodes si vous en avez besoin. En outre, conformément au SRP que j'ai mentionné plus tôt, il devient plus facile d'extraire de nouvelles classes lorsque les méthodes ont été divisées en morceaux plus petits et plus faciles à gérer.

La réponse est bien sûr 42 .

Important à noter: aucune fonction ne peut jamais violer le SRP , ou vous devez faire face à l' inquisition spanisch .

Quelques conseils pour réduire le nombre de lignes:

• Y a-t-il des commentaires marquant des sections individuelles? Ces sections devraient être des fonctions.
• Existe-t-il des chaînes if-else ou des instructions switch en dehors d'une usine / constructeur? Votre conception peut nécessiter de meilleurs modèles de conception pour vous aider à partager les responsabilités.
• Vos fonctions sont-elles faciles à tester? Rendez vos fonctions faciles à tester, elles s'effondreront.
• Est-ce complexe et tout simplement pas de terre en sigth (1000 monstres en ligne)? Faites de la refactorisation de ferraille - c'est de la refactorisation et ne l'enregistrez pas dans l'espoir de vous renseigner sur les responsabilités des codes.

Voici quelques indices:

• Si vous avez du mal à écrire le commentaire expliquant le but et l'utilisation de la fonction, c'est trop long.

• Si vous êtes tenté d'écrire un commentaire expliquant l'activité d'une section de code dans la fonction, alors la fonction est trop longue.

• Si vous collez du code d'une autre fonction, elles sont toutes les deux trop longues (extrayez ce code en tant que fonction distincte).

• Si vous avez besoin d'une convention de codage pour séparer les membres de données de classe des variables locales, la fonction est trop longue et la classe a trop de membres.

• Si vous devez prendre des notes pendant la lecture d'une fonction, c'est trop long.

Avoir des «tonnes» de fonctions, chacune d'une ou deux lignes seulement, n'est pas nécessairement une mauvaise chose. J'ai trouvé que ces petites fonctions étaient réutilisées beaucoup plus que ce à quoi je m'attendais initialement.