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

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 .

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.

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.

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.

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.

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.

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

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.

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.

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.

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.