Quelle est la longueur idéale d'une méthode pour vous? [fermé]

122

En programmation orientée objet, il n’existe bien sûr pas de règle exacte sur la longueur maximale d’une méthode, mais j’ai quand même trouvé ces deux citations qui se contredisaient un peu, je voudrais donc connaître votre opinion.

Dans Clean Code: A Handbook of Agile Software Craftsmanship , Robert Martin déclare:

La première règle de fonctions est qu'ils doivent être petits. La deuxième règle de fonctions est qu'ils doivent être plus petits que cela. Les fonctions ne doivent pas comporter 100 lignes. Les fonctions ne devraient pratiquement jamais être longues de 20 lignes.

et il donne un exemple du code Java qu'il voit de Kent Beck:

Chaque fonction de son programme ne comptait que deux, trois, ou quatre lignes. Chacun était transparent. Chacun a raconté une histoire. Et chacun vous a conduit à l'autre dans un ordre convaincant. Voilà comment vos fonctions devraient être courtes!

Cela sonne bien, mais d'autre part, dans Code Complete , Steve McConnell dit quelque chose de très différent:

La routine doit pouvoir croître de manière organique jusqu’à 100-200 lignes, des décennies de données indiquent que les routines d’une telle longueur ne sont plus sujettes aux erreurs, mais plus courtes.

Et il fait référence à une étude selon laquelle les routines de 65 lignes ou plus sont moins coûteuses à développer.

Ainsi, même si les opinions divergent à ce sujet, existe-t-il une meilleure pratique fonctionnelle pour vous?

iPhoneDeveloper
la source
17
Les fonctions doivent être faciles à comprendre. La longueur devrait en découler, selon les circonstances.
Henk Holterman
56
Je pense que la vraie limite est à 53 lignes. Avec une taille de ligne moyenne de 32,4 caractères. Sérieusement, il n'y a pas de réponse définitive. Une méthode 100 lignes peut être très claire et facile à maintenir, et une méthode 4 lignes peut être un cauchemar à comprendre. Cependant, les méthodes longues ont généralement trop de responsabilités et sont plus difficiles à comprendre et à maintenir que les plus petites. Je penserais en termes de responsabilités et essayerais d'avoir une seule responsabilité par méthode.
23
Il existe un terme dans la programmation appelé «cohérence fonctionnelle». La longueur d'une fonction doit pouvoir varier, à condition que sa mise en œuvre constitue toujours une seule unité logique cohérente dans votre application. Diviser arbitrairement des fonctions pour les réduire est plus susceptible d'alourdir votre code et de nuire à la facilité de maintenance.
9
Et si vous souhaitez limiter la complexité de vos fonctions, vous devez mesurer leur complexité cyclomatique , pas leur longueur. Une switchinstruction avec 100 caseconditions est plus facile à gérer que 10 niveaux d' ifinstructions imbriqués les uns dans les autres.
10
L’approche de Bob Martin est celle de 2008, celle de Steve Mc Connell, celle de 1993. Ils ont des philosophies différentes sur ce qu’est un "bon code", et à mon humble avis, Bob Martin essaie d’obtenir un niveau de qualité de code beaucoup plus élevé.
Doc Brown

Réponses:

115

Les fonctions doivent normalement être courtes, entre 5 et 15 lignes est ma "règle empirique" personnelle lors du codage en Java ou en C #. C'est une bonne taille pour plusieurs raisons:

  • Il s'adapte facilement sur votre écran sans défilement
  • Il s'agit de la taille conceptuelle que vous pouvez garder dans votre tête
  • C'est assez significatif pour exiger une fonction à part entière (en tant que bloc logique significatif et autonome)
  • Une fonction plus petite que 5 lignes est un indice que vous divisez peut-être trop le code (ce qui rend la lecture / compréhension plus difficile si vous devez naviguer entre les fonctions). Ou alors vous oubliez vos cas spéciaux / la gestion des erreurs!

Mais je ne pense pas qu'il soit utile de définir une règle absolue, car il y aura toujours des exceptions / raisons valables pour s'écarter de la règle:

  • Une fonction d'accesseur d'une ligne qui effectue une transtypage est clairement acceptable dans certaines situations.
  • Il existe des fonctions très courtes mais utiles (par exemple, le swap mentionné par un utilisateur inconnu) qui nécessitent clairement moins de 5 lignes. Ce n'est pas grave, quelques fonctions à 3 lignes ne nuisent pas à votre base de code.
  • Une fonction de 100 lignes correspondant à une seule instruction de commutateur de grande taille peut être acceptable si le résultat est extrêmement clair. Ce code peut être très simple d'un point de vue conceptuel même s'il nécessite beaucoup de lignes pour décrire les différents cas. Parfois, il est suggéré de refactoriser cela en classes séparées et de le mettre en œuvre en utilisant l'héritage / polymorphisme, mais à mon humble avis, cela mène trop loin à la POO - je préférerais n'avoir qu'une seule grosse instruction de commutateur à 40 directions plutôt que 40 nouvelles classes à traiter. à une instruction de commutateur à 40 voies pour les créer.
  • Une fonction complexe peut avoir beaucoup de variables d'état qui deviendraient très confuses si elles étaient transmises entre différentes fonctions en tant que paramètres. Dans ce cas, vous pouvez raisonnablement prétendre que le code est plus simple et plus facile à suivre si vous conservez tout dans une seule grande fonction (bien que, comme Mark l’a souligné à juste titre, cela pourrait également être un candidat pour devenir une classe encapsulant à la fois la logique. et état).
  • Parfois, des fonctions plus petites ou plus grandes présentent des avantages en termes de performances (peut-être pour des raisons d'inline ou de JIT, comme le mentionne Frank). Cela dépend fortement de la mise en œuvre, mais cela peut faire une différence - assurez-vous de mesurer!

Donc, fondamentalement, utilisez le bon sens , tenez-vous-en à de petites tailles de fonctions dans la plupart des cas, mais ne soyez pas dogmatique à ce sujet si vous avez vraiment une bonne raison de créer une fonction exceptionnellement grande.

Mikera
la source
9
Il existe également une raison technique / de performance pour les méthodes courtes: les hits de cache JIT. De nombreuses méthodes plus petites et réutilisables ont probablement déjà été appelées auparavant. Oh, et avec un avantage supplémentaire, StackTraces est davantage axé sur la logique qui est devenue populaire.
Luke Puplett
20
"le bon sens" est le conseil le plus important
Simon
Il faut savoir que cette heuristique entraînera des plaintes de "code ravioli" en raison de la profondeur de la pile dans les points d'arrêt, lors du débogage.
Frank Hileman
5
@FrankHileman Je prendrai des raviolis sur des spaghettis tous les jours pour écrire du code
1
@Snowman: ces choix ne sont pas mutuellement exclusifs ... l'idéal est la faible épaisseur des piles sans spaghettis. Profondeurs de la pile, avec des spaghettis sur le côté?
Frank Hileman
30

Bien que je sois d’accord avec les commentaires des autres quand ils disaient qu’il n’y avait pas de règle absolue concernant le bon numéro de LOC, je parie que si nous regardons en arrière des projets que nous avons examinés dans le passé et identifions chaque fonction ci-dessus, disons 150 lignes de code, je ' Je suppose que nous arriverions à un consensus sur le fait que 9 de ces fonctions sur 10 rompent le PRS (et très probablement le PDP), ont trop de variables locales, trop de flux de contrôle et sont généralement difficiles à lire et à maintenir.

Ainsi, bien que LOC ne soit peut-être pas un indicateur direct d'un code incorrect, il s'agit certainement d'un indicateur indirect décent indiquant que certaines fonctions pourraient être mieux écrites.

Dans mon équipe, je suis tombé dans la position de leader et pour une raison quelconque, les gens semblent m'écouter. Ce que j’ai décidé en général, c’est de dire à l’équipe que bien qu’il n’y ait pas de limite absolue, toute fonction comportant plus de 50 lignes de code devrait au minimum déclencher un drapeau rouge lors de la révision du code, afin que nous puissions y jeter un second regard et le réévaluer. pour la complexité et les violations SRP / OCP. Après ce second regard, nous pourrions le laisser seul ou le changer, mais au moins, cela incite les gens à réfléchir à ces choses.

DXM
la source
3
Cela semble raisonnable - la LOC ne veut rien dire en ce qui concerne la complexité ou la qualité du code, mais cela peut être un bon marqueur de la possibilité que les choses soient refactorisées.
Cori
4
"parvenez à un consensus sur le fait que 9 fonctions sur 10 ne respectent pas le PRS" - je ne suis pas d'accord, je suis quasiment sûr que 10 fonctions sur 10 l'exécuteront ;-)
Doc Brown,
1
+1 pour lever un drapeau lors de la révision du code: autrement dit, ce n'est pas une règle absolue, mais discutons de ce code en tant que groupe.
22

Je me suis lancé dans un projet qui ne se souciait pas des directives de codage. Quand je regarde dans le code, je trouve parfois des classes avec plus de 6000 lignes de code et moins de 10 méthodes. C'est un scénario d'horreur lorsque vous devez corriger des bugs.

Une règle générale de la taille maximale d'une méthode n'est parfois pas très bonne. J'aime la règle de Robert C. Martin (Oncle Bob): "Les méthodes doivent être petites, plus petites que petites". J'essaie d'utiliser cette règle tout le temps. J'essaie de garder mes méthodes simples et modestes en précisant que ma méthode ne fait qu'une chose et rien de plus.

Smokefoot
la source
4
Je ne vois pas pourquoi une fonction de 6000 lignes est plus difficile à déboguer qu'une autre plus courte ... Sauf si elle a aussi d'autres problèmes (par exemple, la répétition)
Calmarius
17
Cela n’a rien à voir avec le débogage. C’est une question de complexité et de maintenabilité. Comment étendre ou modifier une méthode de 6000 lignes effectuée par une autre?
Smokefoot
10
@Calmarius, la différence est généralement que les fonctions de 6000 lignes contiennent généralement des variables locales déclarées très loin (visuellement), ce qui complique la tâche du programmeur pour créer le contexte mental requis pour avoir une grande confiance dans le code. Pouvez-vous être sûr de la manière dont une variable est initialisée et construite à un moment donné? Etes-vous sûr que rien ne va jouer avec votre variable après l'avoir définie sur la ligne 3879? D'autre part, avec 15 méthodes de ligne, vous pouvez être sûr.
Daniel B
8
@ Calmarius a accepté, mais ces deux déclarations sont un argument contre 6000 fonctions LOC.
Daniel B
2
Une variable locale dans une méthode à 600 lignes est essentiellement une variable globale.
MK01
10

Il ne s'agit pas du nombre de lignes, mais du SRP. Selon ce principe, votre méthode devrait faire une et une seule chose.

Si votre méthode fait ceci ET ceci ET ceci OU cela => il en fait probablement trop. Essayez de regarder cette méthode et d’analyser: "Ici, je reçois ces données, les trie et obtiens les éléments dont j'ai besoin" et "ici, je traite ces éléments" et "je les combine enfin pour obtenir le résultat". Ces "blocs" doivent être reformulés selon d'autres méthodes.

Si vous suivez simplement SRP, la plupart de vos méthodes seront petites et d’intention claire.

Il n'est pas correct de dire "cette méthode a plus de 20 lignes, donc c'est faux". Cela peut indiquer que quelque chose ne va pas avec cette méthode, pas plus.

Vous pouvez avoir un commutateur de 400 lignes dans une méthode (cela se produit souvent dans les télécommunications), et cela reste une responsabilité unique et tout va bien.

Alexey
la source
2
Les grandes instructions de commutateur, le formatage de sortie, les définitions de hachages / dictionnaires qui devraient être codés en dur plutôt que flexibles dans certaines bases de données, cela arrive souvent, et cela va parfaitement. Tant que la logique est divisée, alors vous êtes tous bons. Une grande méthode pourrait vous inciter à penser «devrais-je diviser cela». La réponse pourrait très bien être "non, c'est bien comme ça" (ou oui, c'est un gâchis absolu)
Martijn
Que signifie "SRP"?
Thomthom
3
SRP signifie Principe de responsabilité unique et stipule que chaque classe (ou méthode) ne devrait avoir qu'une seule responsabilité. Il est lié à la cohésion et au couplage. Si vous suivez le SRP, vos classes (ou méthodes) auront une bonne cohésion, mais le couplage peut être augmenté car vous vous retrouvez avec plus de classes (ou méthodes).
Kristian Duske
+1 pour SRP. En écrivant des fonctions cohérentes, on peut alors plus facilement les combiner dans un style fonctionnel pour obtenir des résultats plus complexes. En fin de compte, il vaut mieux qu'une fonction soit composée de trois autres fonctions collées plutôt que d'avoir une seule fonction réalisant trois choses distinctes, même si elles sont liées d'une manière ou d'une autre.
Mario T. Lanza
Oui, mais quelle est une responsabilité unique. C'est juste un concept créé dans votre tête. Si vous avez besoin de 400 lignes pour une responsabilité unique, votre conception de la responsabilité unique est probablement bien différente de la mienne
Xitcod13
9

Cela dépend , sérieusement, il n’ya vraiment pas de réponse solide à cette question car le langage avec lequel vous travaillez est important, les lignes 15 à 15 mentionnées dans cette réponse peuvent fonctionner en C # ou en Java, mais cela ne donne pas vous avez beaucoup de travail avec. De même, selon le domaine dans lequel vous travaillez, vous pouvez éventuellement écrire des valeurs de paramétrage de code dans une structure de données volumineuse. Avec certaines structures de données, vous pouvez avoir à définir des dizaines d’éléments. Devriez-vous créer des séparations pour séparer des fonctions simplement parce que votre fonction est longue?

Comme d'autres l'ont noté, la meilleure règle à suivre est qu'une fonction doit être une seule entité logique qui gère une seule tâche. Si vous essayez d'appliquer des règles draconiennes stipulant que les fonctions ne peuvent pas être plus longues que n lignes et que vous réduisez cette valeur à une valeur trop petite, votre code deviendra plus difficile à lire, car les développeurs essaient d'utiliser des astuces sophistiquées pour contourner la règle. De même, si vous le définissez trop haut, ce ne sera pas un problème et peut conduire à un code incorrect si vous êtes paresseux. Votre meilleur choix est simplement de passer en revue les codes pour vous assurer que les fonctions gèrent une tâche unique et en rester là.

rjzii
la source
8

Je pense qu'un problème ici est que la longueur d'une fonction ne dit rien sur sa complexité. Les lignes de code (LOC) sont un mauvais instrument pour mesurer quoi que ce soit.

Une méthode ne doit pas être trop complexe, mais il existe des scénarios dans lesquels une méthode longue peut être facilement maintenue. Notez que l'exemple suivant n'indique pas qu'il ne peut pas être divisé en méthodes, mais que ces méthodes ne modifieraient pas la maintenabilité.

Par exemple, un gestionnaire pour les données entrantes peut avoir une instruction switch importante puis un code simple par cas. J'ai un tel code - gérer les données entrantes à partir d'un flux. 70 (!) Gestionnaires codés numériquement. Maintenant, on dira "utiliser des constantes" - oui, sauf que l'API ne les fournit pas et j'aime rester près de "source" ici. Les méthodes? Bien sûr, malheureusement, ils traitent tous de données provenant des mêmes 2 grandes structures. Aucun avantage à les séparer sauf peut-être avoir plus de méthodes (lisibilité). Le code est intrinsèquement peu complexe - un commutateur, en fonction du champ. Ensuite, chaque cas a un bloc qui analyse x éléments de données et les publie. Pas de cauchemar d'entretien. Il y a une condition "répétant" qui détermine si un champ a des données (pField = pFields [x], si pField-> IsSet () {blabla}) - la même chose pour tous les champs ..

Remplacez-la par une routine beaucoup plus petite contenant une boucle imbriquée et un grand nombre d'instructions de commutation réelles et une méthode énorme peut être plus facile à gérer qu'une autre plus petite.

Donc, désolé, LOC n'est pas une bonne mesure pour commencer. Le cas échéant, les points de complexité / décision doivent être utilisés.

TomTom
la source
1
Les lettres de crédit sont un bon outil à utiliser pour le domaine dans lequel elles fournissent une mesure pertinente - les très grands projets où elles peuvent être utilisées pour aider à donner une estimation de la durée nécessaire à la réalisation d’un projet similaire. Au-delà de cela, les gens ont tendance à trop se soucier d'eux.
rjzii
Droite. Ce n’est pas comme si LOC ne dépendait pas tellement de mon expression du code, de ses exigences en matière de formatage, etc. Seulement. Vous êtes libre de vous inscrire sur la liste des personnes qui ne comprennent pas pourquoi les lettres de crédit sont une mauvaise mesure, mais cela ne vous fera clairement pas paraître comme une personne à écouter.
TomTom
Veuillez relire ce que j’ai dit à nouveau. J’ai noté que les lettres de crédit ne sont un bon outil que pour un domaine de mesure et d’utilisation (c’est-à-dire des projets extrêmement volumineux où elles peuvent être utilisées pour des estimations). N'importe quoi de plus petit que la grande échelle et ils utilisent la plupart sinon la totalité de la valeur pour tout ce qui va au-delà des notes sonores rapides dans les réunions pour garder les gens heureux. C'est un peu comme essayer d'utiliser des années-lumière pour mesurer la justesse du café au bureau. Bien sûr, vous pouvez le faire, mais la mesure est inutile. Mais lorsque vous devez discuter des distances entre les étoiles, elles fonctionnent parfaitement.
Rjzii
2
+1 une fonction doit avoir tout le code nécessaire pour l'exécuter. Il devrait faire une chose et une seule chose - mais si cela prend 1000 lignes de code, alors qu’il en soit ainsi.
James Anderson
J'ai écrit des gestionnaires pour les données de socket entrantes et, oui, ils peuvent nécessiter un millier de LOC ou plus. Cependant, je peux compter sur une main le nombre de fois où j'ai eu besoin de le faire et je ne peux pas compter le nombre de fois où ce n'était pas la bonne façon de coder.
7

Je vais juste ajouter une autre citation.

Les programmes doivent être écrits pour que les gens puissent les lire et, accessoirement, pour que les machines puissent les exécuter.

- Harold Abelson

Il est très improbable que les fonctions qui atteignent 100-200 suivent cette règle

Pete
la source
1
Sauf quand ils contiennent un interrupteur.
Calmarius
1
ou construisez un objet en fonction des résultats d'une requête de base de données
renvoyant des
Les résultats de la base de données sont certainement une exception acceptable. De plus, ce sont généralement des instructions "stupides" qui renseignent certaines instances d'une classe (ou autre) plutôt que la logique qu'il convient de suivre.
MetalMikester
6

Je suis dans cette raquette folle, d’une manière ou d’une autre, depuis 1970.

Pendant tout ce temps, à deux exceptions près, je n’aurai JAMAIS vu une "routine" bien conçue (méthode, procédure, fonction, sous-programme, etc.) devant BESOIN d’avoir plus d’une page imprimée ( environ 60 lignes) de long. La grande majorité d'entre eux étaient assez courts, de l'ordre de 10 à 20 lignes.

Cependant, j'ai vu BEAUCOUP de code de "flux de conscience", écrit par des personnes qui n'avaient apparemment jamais entendu parler de la modularisation.

Les deux exceptions étaient des cas très particuliers. L'une d'elles est en fait une classe de cas exceptionnels, que je regroupe: de grands automates à états finis, implémentés sous la forme de grandes instructions de commutateur laides, généralement parce qu'il n'y a pas de moyen plus clair de les implémenter. Ces éléments apparaissent généralement dans l'équipement de test automatisé, analysant les journaux de données du périphérique testé.

L'autre était la routine de torpille à photons du jeu STARTRK Matuszek-Reynolds-McGehearty-Cohen, écrite en CDC 6600 Fortran IV. Il devait analyser la ligne de commande, puis simuler le vol de chaque torpille, avec des perturbations, vérifier l’interaction entre la torpille et chaque type de chose qu’elle pouvait frapper, et, au passage, simuler la récursivité pour établir une connectivité à 8 voies sur des chaînes de données. novae de torpiller une étoile qui était à côté d’autres étoiles.

John R. Strohm
la source
2
+1 pour l’ambiance "lève-toi de ma pelouse" que je tire de cette réponse. De plus, l'expérience personnelle d'avant la POO était répandue.
Ce n'est pas tellement «sors de ma pelouse», mais plutôt l'observation que j'ai vu BEAUCOUP de code de merde au fil des ans, et que ça semble empirer.
John R. Strohm
Mon patron a l'habitude d'écrire des méthodes de plusieurs centaines de lignes, souvent avec plusieurs niveaux de if imbriqués. Il utilise également des classes partielles (.NET) pour "décomposer" une classe en plusieurs fichiers afin qu'il puisse prétendre qu'il est court. Ce ne sont que deux choses que je dois traiter. Je fais cela depuis environ 25 ans, et je peux confirmer que la situation empire. Et maintenant, il est temps que je retourne dans ce pétrin.
MetalMikester
5

Si je trouve la méthode longue, je pourrais parier que cette méthode n’est pas correctement testée ou que la plupart du temps elle n’a pas du tout de test unitaire. Si vous commencez à utiliser TDD, vous ne construirez jamais de méthodes 100 lignes avec 25 responsabilités différentes et 5 boucles imbriquées. Les tests vous obligent à refactoriser constamment votre désordre et à écrire le code propre à oncle Bob.

Sergii Shevchyk
la source
2

Il n'y a pas de règles absolues sur la longueur de la méthode, mais les règles suivantes ont été utiles:

  1. Le but principal de la fonction est de trouver la valeur de retour. Il n'y a pas d'autre raison pour son existence. Une fois cette raison remplie, aucun autre code ne doit y être inséré. Cela garde nécessairement les petites fonctions. L'appel d'autres fonctions ne doit être effectué que si cela facilite la recherche de la valeur de retour.
  2. D'autre part, les interfaces doivent être petites. Cela signifie que vous avez soit un grand nombre de classes, soit de grandes fonctions - l'une des deux se produira une fois que vous aurez assez de code pour faire quelque chose d'important. Les gros programmes peuvent avoir les deux.
tp1
la source
1
Qu'en est-il des effets secondaires - écriture dans un fichier, réinitialisation du statut, etc.?
Vorac
2

Les auteurs entendent-ils la même chose par "fonction" et par "routine"? Typiquement, quand je dis "fonction", je veux dire un sous-programme / une opération qui retourne une valeur et une "procédure" pour un autre qui ne le fait pas (et dont l'appel devient une seule instruction). Ce n'est pas une distinction commune à travers SE dans le monde réel mais je l'ai vue dans des textes utilisateur.

De toute façon, il n'y a pas de bonne réponse à cela. La préférence pour l’un ou l’autre (s’il ya une préférence du tout) est quelque chose de très différent selon les langues, les projets et les organisations; exactement comme avec toutes les conventions de code.

Le bit que j’ajouterais, c’est que l’assertion entière «les opérations longues ne sont pas plus sujettes aux erreurs que les opérations courtes» n’est pas strictement vraie. En plus du fait que plus de code équivaut à plus d’espace potentiel d’erreurs, il est tout à fait évident que briser le code en segments rendra les erreurs plus faciles à éviter et à localiser. Sinon, il n'y aurait aucune raison de diviser le code en morceaux, sauf la répétition. Mais cela n’est peut-être vrai que si ces segments sont suffisamment documentés pour que vous puissiez déterminer les résultats d’un appel d’opération sans lire ou suivre le code réel (conception par contrat basée sur des spécifications plutôt que par une dépendance concrète entre des zones de code).

En outre, si vous souhaitez que les opérations plus longues fonctionnent correctement, vous pouvez adopter des conventions de code plus strictes pour les prendre en charge. Tossing une instruction de retour au milieu d'une opération peut convenir pour une opération courte, mais dans les opérations plus longues, cela peut créer une grande section de code conditionnelle mais pas évidemment conditionnée à une lecture rapide (juste pour un exemple).

Donc, je penserais que le style qui est le moins susceptible d’être un cauchemar rempli de bogues dépendrait en grande partie des conventions que vous respectez pour le reste de votre code. :)

Trixie Wolf
la source
1

IMHO, vous ne devriez pas avoir à utiliser la barre de défilement pour lire votre fonction. Dès que vous avez besoin de déplacer la barre de défilement, il vous faut un peu plus de temps pour comprendre le fonctionnement de la fonction.

En conséquence, cela dépend de l'environnement de programmation habituel de votre travail d'équipe (résolution de l'écran, éditeur, taille de la police, etc.). Dans les années 80, c'était 25 lignes et 80 colonnes. Maintenant, sur mon éditeur, j'affiche près de 50 lignes. Le nombre de colonnes que j’affiche n’a pas changé depuis que j’ai divisé mon écran en deux pour afficher deux fichiers à la fois.

En bref, cela dépend de la configuration de vos collègues.

Jérôme Pouiller
la source
2
N'était-ce pas plutôt 24 lignes à cette époque? Je pense aux terminaux 3270 ou 9750, où le 25 était la ligne d'état. Et les émulations de terminaux ont suivi cela.
ott--
certains systèmes / éditeurs avaient 40 ou 50 lignes depuis le début. De nos jours, 150 lignes n’est pas rare et 200+ est faisable, ce n’est donc pas vraiment une bonne mesure.
MOZ
J'utilise mon écran en orientation portrait, je peux voir 200 lignes de code à la fois.
Calmarius
et si je n'utilise pas de saut de ligne pour rompre mes lignes, je peux coder une méthode de 5000 lignes en une seule ligne ...
jwenting
1

Je pense que la réponse de TomTom est proche de ce que je ressens à ce sujet.

De plus en plus, je me retrouve plutôt dans la complexité cyclomatique que dans les lignes.

Normalement, je ne vise pas plus d'une structure de contrôle par méthode, à l'exception du nombre de boucles nécessaire pour gérer un tableau multidimensionnel.

Je me trouve parfois dans les cas où il y a un changement de ligne parce que, pour une raison quelconque, ce sont généralement des cas où le fractionnement nuit au lieu d'aider.

Notez que je ne compte pas la logique de garde contre cette limite.

Loren Pechtel
la source
Il a été démontré que la complexité cyclomatique, sur de grandes quantités de code de production réel, était TRÈS fortement corrélée au SLOC brut, ce qui fait du calcul de la complexité cyclomatique un gaspillage total de cycles de temps, d’énergie et d’horloge.
John R. Strohm
@ JohnR.Strohm je parle par méthode, pas globalement. Bien sûr, dans l’ensemble, il est fortement corrélé - la question est de savoir comment scinder ce code en méthodes. 10 méthodes de 100 lignes ou 100 méthodes de 10 lignes auront toujours le même SLOC et la même complexité, mais la première sera beaucoup plus difficile à utiliser.
Loren Pechtel
Moi aussi. L'étude de corrélation a examiné beaucoup de code et beaucoup de routines. (C'était l'un des grands dépôts publics.)
John R. Strohm
-3

Dans OOP, toutes les choses s'opposent et présentent les caractéristiques suivantes:

  1. Polymorphisme
  2. Abstraction
  3. Héritage

Lorsque vous respectez ces règles, vos méthodes sont généralement petites, mais il n'existe aucune règle pour les règles petites ou très petites (par exemple, 2 ou 3 lignes). Les avantages d’une petite méthode (petite unité, par exemple méthode ou fonction) sont les suivants:

  1. mieux lisible
  2. maintenir mieux
  3. bug corrigé mieux
  4. change mieux
Sam
la source