Combien de lignes par classe est trop en Java? [fermé]

74

Selon votre expérience, quelle est la règle empirique utile pour combien de lignes de code sont trop pour une classe en Java?

Pour être clair, je sais que le nombre de lignes n’est même pas proche du véritable standard à utiliser pour ce qui devrait être dans une classe particulière et ce qui ne devrait pas. Les classes doivent être conçues selon les principes de la programmation orientée objet (encapsulation, etc.). Cela dit, une règle empirique pourrait fournir un point de départ utile pour les considérations de refactoring (par exemple, "Hmmm, cette classe a> n lignes de code; elle est probablement illisible et fait un travail d'encapsulation moche, je pourrais donc vouloir voir si elle devrait être refactorisé à un moment donné ").

D'un autre côté, avez-vous peut-être rencontré des exemples de très grandes classes qui respectent toujours bien la conception POO, qui sont lisibles et peuvent être maintenues malgré leur longueur?

Voici une question connexe, non dupliquée, sur les lignes par fonction .

java programming-practices refactoring Michael McGowan
la source
4
J'ai vu des cours avec plus de mille lignes, je ne pense pas qu'il y ait une telle chose comme "trop".
Mahmoud Hossam
5
C'est trop quand il ne compile plus. Sérieusement, ce n'est que trop lorsque la classe fait trop de choses différentes.
Berin Loritsch le
20
Une règle empirique se transforme en un maximum qui se transforme en une politique qui se transforme en un désaccord. Évitez la numérité. Compter et mesurer ne sont pas le moyen idéal pour établir si les responsabilités ont été attribuées correctement.
S.Lott
7
À peu près le même que le nombre correct de pouces pour un morceau de ficelle.
Matt
6
Une question avec 30 votes, consultée ~ 24k fois, 10 réponses avec (collectivement) ~ 75 votes. "fermé comme étant principalement basé sur l'opinion" Bienvenue dans l'échange de pile :) Il faut que quelque chose change dans la culture de la SE ...
jb.

Réponses:

79

Quelques métriques intéressantes:

            junit fitnesse testNG tam jdepend ant tomcat
            ----- -------- ------ --- ------- --- ------
max 500 498 1450 355 668 2168 5457
moyenne 64,0 77,6 62,7 95,3 128,8 215,9 261,6
min 4 6 4 10 20 3 12
Sigma 75 76 110 78 129 261 369
fichiers 90 632 1152 69 55 954 1468
total des lignes 5756 49063 72273 6575 7085 206001 384026

J'utilise FitNesse comme point de repère parce que j'ai beaucoup contribué à l'écrire. Dans FitNesse, la classe moyenne compte 77 lignes. Aucune ne dépasse 498 lignes. Et l’écart type est de 76 lignes. Cela signifie que la grande majorité des classes ont moins de 150 lignes. Même Tomcat, qui a une classe de plus de 5000 lignes, a moins de 500 lignes pour la plupart.

Compte tenu de cela, nous pouvons probablement utiliser 200 lignes comme une bonne ligne de conduite pour rester en dessous.

Oncle Bob.
la source
9
Si la classe n'a qu'une responsabilité, les chances qu'elle dépasse 200 à 500 lignes sont plutôt minces. Ceux qui le font ont généralement des "classes internes" pour gérer d'autres responsabilités connexes . Par exemple, la classe de ligne Tomcat 5000+ peut vraiment être une classe principale avec une douzaine de classes internes. Ce n'est pas inhabituel en Java où vous avez des gestionnaires de requêtes et autres.
Berin Loritsch
4
comment obtient-on ces métriques, vraiment? je veux juste savoir
Sнаđошƒаӽ le
1
Je me pencherais plutôt plus vers cette réponse à la question liée aux fonctions: programmers.stackexchange.com/a/9452/100669 Le LOC est un peu sans importance, sauf que c'est peut-être une règle générale extrêmement générale de simplement se demander si vous pourriez être capable de décomposer les choses plus loin. Et je suis d'accord sur le problème des classes imbriquées. Néanmoins, 500 est probablement plus proche d'un panneau d'avertissement général.
Panzercrisis
@ Sнаđошƒаӽ github.com/AlDanial/cloc
firephil
32

Pour moi, les lignes de code ne sont pas pertinentes dans ce contexte. Tout dépend du nombre de raisons pour lesquelles je viendrais dans cette classe pour le changer.

Si je veux venir dans cette classe quand je veux changer les règles de validation d'une personne, je ne veux pas venir dans la même classe pour changer les règles de validation d'une commande, je ne veux pas non plus venir ici pour changer persister une personne.

Cela dit, si vous visez cela, vous trouverez rarement des classes dépassant 200 lignes. Ils se produiront, pour des raisons valables, mais ils seront rares. Donc, si vous cherchez une mesure du drapeau rouge, ce n'est pas un mauvais point de départ. mais en faire une ligne directrice, pas une règle.

pdr
la source
200 semble être une estimation approximative. Comme tu le dis, pas la chose qui t'inquiète d'abord.
Steve
La seule chose à propos de Java, c’est que, lors du décompte des lettres de crédit, j’ignorerais les accesseurs.
MrFox
1
@ MrFox: Je ne suis pas d'accord. Si votre classe dispose d'assez de getters et de setters pour fausser les données LOC, cela compte dans le "est-ce que cette classe en fait trop?" question. Cependant, comme compromis, je serais prêt à choisir / régler NetBean à moins d’une ligne par ligne, par respect pour les méthodes excessives utilisées par de telles méthodes.
Brian
23

Je suis désolé mais je suis très surpris que de nombreuses réponses indiquent que cela "n'a pas vraiment d'importance". Le nombre de lignes dans une classe compte BEAUCOUP. Pourquoi? Considérez ces principes en écrivant un bon code Java ...

  • Testabilité
  • Cohésion
  • Couplage
  • Compréhensibilité

Les classes comportant beaucoup de lignes vont probablement enfreindre tous ces principes.

Pour ceux qui ont déclaré que "peu importe" ... à quel point cela vous a-t-il été amusant d'essayer de comprendre une classe de plus de 5000 lignes? Ou, pour le modifier? Si vous dites que c'est amusant, vous avez une étrange affinité avec la douleur ...

Je dirais que toute classe comportant plus de 1 000 lignes doit au moins être interrogée sur la manière dont elle pourrait violer les principes ci-dessus et éventuellement être divisée en plusieurs classes "dérivées".

Mes commentaires sont basés sur la lecture et l’étude d’auteurs tels que Martin Fowler, Joshua Bloch et Misko Hevery. Ce sont d’excellentes ressources à consulter pour écrire du bon code Java.

Faites une faveur au prochain gars (qui pourrait être vous dans quelques années) et essayez d’écrire des classes qui contiennent moins de lignes que plus de lignes.

Zack Macomber
la source
Je pense que tout le monde est d'accord pour dire que 5000+ n'est généralement pas un bon signe (sans compter les classes imbriquées), mais ils ont l'impression que c'est plus un effet secondaire ou quelque chose de ce que le problème réel. Bien sûr, certaines personnes sont trop verbeuses et utilisent un nombre excessif de lignes simplement pour déclarer et initialiser des variables, etc. - et elles doivent arrêter cela. Cela le rend moins lisible. Mais si cela concerne la structure de classe, le problème n'est pas le LOC lui-même; c'est le fait que quelqu'un ne divise pas très bien les choses pour commencer, et le COL est un effet secondaire de cela.
Panzercrisis
2
Le fait est qu’une classe doit avoir une grande cohésion et une responsabilité claire, ce qui signifie que les classes ne grandissent généralement pas si gros. Mais si une classe est bien conçue mais comporte toujours plus de 5000 lignes de code, cela n'aide personne à la scinder en plusieurs classes plus petites et étroitement associées.
JacquesB
12

Cela dépend de la complexité, pas du nombre de lignes. J'ai écrit de grosses routines stupides, faciles à comprendre, qui ont précisément fait une chose et l'ont bien fait, mais qui ont duré des centaines de lignes. J'ai écrit des fonctions assez courtes et difficiles à comprendre (et à déboguer).

Une autre chose à considérer est le nombre de fonctions publiques dans une classe. Cela peut aussi être un signe d'avertissement.

Je n'ai pas de bons chiffres disponibles, mais je suggérerais de regarder un code décent qui fait des choses utiles dans votre magasin, et de le baser sur cela. Vous devriez certainement consulter les classes les plus longues et les plus grandes API.

David Thornley
la source
7
+1: Ne mesurez pas des choses stupides comme des lignes. La complexité cyclomatique et le nombre de fonctions (nombre de méthodes) donnent plus de sens aux lignes.
S.Lott
2
Oui et non. Un nombre excessif de lignes est souvent le symptôme d'une mauvaise conception et constitue donc un signal d'alarme indiquant que la classe a probablement besoin d'une refactorisation.
Jwenting
1
@jwenting Oui, c'est ce à quoi je voulais en venir. Je sais que beaucoup de lignes! = Doivent être refactorisées, mais presque toutes les classes avec lesquelles je travaille ont vraiment besoin d’être refactorées car leur conception est médiocre.
Michael McGowan
5

Il y a trop de lignes de code si la classe fait trop de choses différentes. Essentiellement, si vous suivez le principe de responsabilité unique pour les classes, il y a une limite à la taille de la classe.

En ce qui concerne les limitations physiques, vous pouvez avoir (source: format de fichier de classe Java5 ):

  • 65 536 constantes, interfaces appliquées, champs, méthodes et attributs - chacun. REMARQUE: vous manquerez d'espace constant avant de manquer de tout autre élément. NOTE 2: les attributs sont des constructions de fichier de classe - à ne pas confondre avec les marqueurs '@Attribute' (les informations de débogage et le code d'octet sont stockés en tant qu'attributs distincts pour une méthode).
  • Chaque méthode peut représenter 4 Go (32 bits) de code octet généré. REMARQUE: Les versions Java antérieures à la version 1.5 ne pouvaient contenir que 64 Ko (16 bits) de code octet généré pour chaque méthode.

En bref, le fichier de classe peut être beaucoup plus volumineux que quiconque jugerait utile. Si vous vous en tenez au principe de responsabilité unique, vos fichiers de classe auront la bonne taille.

Berin Loritsch
la source
1
+1 pour une responsabilité unique :) @Berin l'implémentez-vous strictement dans votre logiciel?
Aditya P
Oui. L'astuce consiste à répartir les responsabilités de manière logique.
Berin Loritsch le
ah, la bonne vieille limite de 64Ko. Beau test lithmus pour voir si vos JSP sont trop complexes, car ils sont traduits en une seule méthode avec de nombreuses instructions println pour tous vos
fichiers
Depuis Java 5, ils ont augmenté à 4 Go. Pas de soucis là maintenant.
Berin Loritsch le
5

La bonne réponse est 42. Je plaisante.
En réalité, le nombre maximum de lignes recommandées par classe est de 2000 lignes.

Les "conventions de code Java" depuis 1999 l’énoncent ainsi: Les
fichiers de plus de 2000 lignes sont fastidieux et doivent être évités.

Ayant suivi les conventions de codage Sun / Oracle depuis l’invention de Java, j’ai trouvé que cette règle empirique sur les lignes par classe était raisonnable. 99% de votre code Java devrait être conforme ... Et s'il dépasse 2000, placez simplement un TODO en haut de l'écran pour indiquer que la classe a besoin de travail.

Le pire est le cas contraire lorsque les programmeurs créent trop de petites classes sans pratiquement aucune fonctionnalité réelle dans chaque classe. Ignorant le conseil de "Favoriser la composition", les programmeurs créent des centaines de classes héritées qui créent des modèles d'objet complexes bien pires que le problème des grandes classes (qui conservent au moins la fonctionnalité avec un nom de classe pertinent).

http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.html#3043

utilisateur1865223
la source
En fait, la plupart d'entre eux sont des commentaires @LluisMartinez
Xtreme Biker
Je suis fortement en désaccord avec 2000 . Une classe ne doit pas dépasser 200 lignes sans les commentaires.
Nikolas
4

Code propre:

Les classes devraient être petites!

La première règle des classes est qu'elles doivent être petites. La deuxième règle des classes est qu'elles doivent être plus petites que cela. Non, nous n'allons pas répéter exactement le même texte du chapitre Fonctions. Mais comme pour les fonctions, plus petite est la règle principale lors de la conception de classes. Comme pour les fonctions, notre question immédiate est toujours "Quelle taille?"

** Avec les fonctions, nous avons mesuré la taille en comptant les lignes physiques. Avec les classes, nous utilisons une mesure différente. Nous comptons les responsabilités. **

Le nom d’une classe doit décrire les responsabilités qu’elle remplit. En fait, nommer est probablement le premier moyen d’aider à déterminer la taille de la classe. Si nous ne pouvons pas dériver un nom concis pour une classe, alors il est probablement trop grand. Plus le nom de la classe est ambigu, plus il est probable qu'il a trop de responsabilités. Par exemple, les noms de classe comprenant des mots anonymes tels que Processor ou Manager ou Super suggèrent souvent une agrégation malheureuse de responsabilités.

Ensuite:

  • Assurez-vous simplement que vos méthodes ne font qu'une chose.
  • Ensuite, assurez-vous que la classe n'a pas trop de responsabilités.

Vous allez vous retrouver avec une classe d'une taille gérable.

Tulains Córdova
la source
si Clean Codeen plus de votre réponse se réfère au livre de Robert C. Martin (ce qui est le cas!), alors je dois vous dire et je l’ai en commun; ce livre est ce qui m'a amené à cette question. Je pense que cette réponse dit tout
Sнаđошƒаӽ le
2

Le nombre de lignes est une métrique assez médiocre pour la qualité de classe. Pour moi, j'aime bien (comme d'autres l'ont déjà mentionné) les méthodes publiques, ainsi que toutes les propriétés exposées publiquement (j'imagine, les getters / setters publics en Java). Si je devais extraire un chiffre du moment où il pourrait attirer mon attention, je dirais quand il y en a plus de 10 de chaque. Vraiment, si c'est plus que 5 propriétés ou méthodes, je jetterai un œil et trouverai souvent des façons de refactoriser, mais tout ce qui dépasse 10 est habituellement un signe avant-coureur que quelque chose risque d'être mal exposé.

C’est une autre conversation, mais les méthodes et les champs privés sont moins odorants pour moi. Par conséquent, s’ils contribuent beaucoup au nombre de lignes, je ne serais peut-être pas aussi inquiet. À tout le moins, cela montre qu'il n'y a probablement pas de contrôleur de Dieu manipulant l'objet de loin, ce qui pose de jolis problèmes de conception.

Morgan Herlocker
la source
2

Essayez d'utiliser une meilleure métrique.

Un exemple est la métrique ABC . Il s'agit davantage d'une mesure de la quantité de travail effectuée par le code que de la quantité de code existante.

Sylvanaar
la source
1

Toute ligne entrant dans le domaine problématique de votre classe et écrite en dehors de la classe constitue une ligne de trop et une de trop dans la classe où elle habite. Pensez à une classe en tant que sujet. Vous devez le couvrir. De manière aussi concise que possible, c'est l'idéal, mais s'il faut 500 lignes, il faut 500 lignes. Si 100 de ces lignes couvrent un autre sujet, elles appartiennent ailleurs. Diviser en sous-domaines plus petits au sein de la classe en tant que classes intérieures a du sens, mais je ne définirais ceux qui sont en dehors de la classe que s'ils avaient été utilisés ailleurs.

Erik Reppen
la source