Combien de lignes par classe est trop en Java?
D'après votre expérience, quelle est la règle d'or utile pour combien de lignes de code sont trop nombreuses pour une classe en Java?
Pour être clair, je sais que le nombre de lignes n'est même pas proche du vrai standard à utiliser pour ce qui devrait être dans une classe particulière et ce qui ne devrait pas. Les classes doivent être conçues en tenant compte des philosophies appropriées de OOP (encapsulation, etc.). Cela dit, une règle de base pourrait fournir un point de départ utile pour des considérations de refactorisation (c.-à-d. "Hmmm, cette classe a> n lignes de code; il est probablement illisible et fait un mauvais travail d'encapsulation, donc je pourrais vouloir voir s'il devrait être refactorisé à un moment donné ").
D'un autre côté, avez-vous peut-être rencontré des exemples de très grandes classes qui obéissaient toujours à OOP bien conçues et lisibles et maintenables malgré leur longueur?
Voici une relation connexe non dupliquée question 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 20 3 12 sigma 75 76 110 78 129 261 369 Dossiers 90 632 1152 69 55 954 1468 Lignes totales 5756 49063 72273 6575 7085 206001 384026
J'utilise FitNesse comme référence car j'avais beaucoup à voir avec son écriture. Dans FitNesse, la classe moyenne est de 77 lignes. Aucun 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 la plupart des classes de moins de 500 lignes.
Compte tenu de cela, nous pouvons probablement utiliser 200 lignes comme bonne ligne directrice pour rester en dessous.
Pour moi, les lignes de code ne sont pas pertinentes dans ce contexte. Tout dépend du nombre de raisons différentes pour lesquelles je viendrais dans ce cours pour le changer.
Si je venais dans cette classe quand je veux changer les règles pour valider une personne, je ne veux pas venir dans la même classe pour changer les règles pour valider une commande, je ne veux pas non plus venir ici pour changer où je persister une personne.
Cela dit, si vous visez cela, vous trouverez rarement des classes de plus de 200 lignes. Ils se produiront, pour des raisons valables, mais ils seront rares. Donc, si vous recherchez une mesure de 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 déclarent que "cela n'a pas vraiment d'importance". Cela dépend beaucoup du nombre de lignes dans une classe. Pourquoi? Considérez ces principes en écrivant un bon Java code ...
- Testabilité
- Cohésion
- Couplage
- Compréhensibilité
Les classes contenant beaucoup de lignes violeront très probablement tous ces principes.
Pour ceux qui ont déclaré que "ça n'a pas vraiment d'importance" ... à quel point cela vous a-t-il amusé d'essayer de comprendre une classe qui contient 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 qui contient plus de 1000 lignes devrait au moins être interrogés sur la façon dont ils peuvent violer les principes ci-dessus et éventuellement analysés en plusieurs classes "hors-tournage".
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 un bon code Java.
Rendez service au gars suivant (qui pourrait être vous dans quelques années) et efforcez-vous d'écrire des cours qui contiennent moins que plus de lignes.
Cela dépend de la complexité et non du nombre de lignes. J'ai écrit de grosses routines stupides qui étaient faciles à comprendre et qui ont fait exactement une chose et l'ont bien fait, mais qui ont duré des centaines de lignes. J'ai écrit des fonctions assez courtes qui étaient difficiles à comprendre (et à déboguer).
Une autre chose que vous pourriez examiner est le nombre de fonctions publiques dans une classe. Cela peut également être un signe d'avertissement.
Je n'ai pas de bons décomptes disponibles, mais je suggérerais de regarder du code décent qui fait des choses utiles dans votre boutique, et de le baser sur cela. Vous devriez certainement regarder les classes les plus longues et les plus grandes API.
La bonne réponse est 42. Je plaisante.
En fait, le nombre maximal de lignes recommandées par classe est 2000 lignes.
Les "conventions de code Java" depuis 1999 l'ont déclaré ainsi:
Les fichiers de plus de 2 000 lignes sont encombrants et doivent être évités.
Ayant suivi les conventions Sun/Oracle Coding depuis Java a été inventé, j'ai trouvé cette règle empirique sur les lignes par classe raisonnable. 99% de votre Java = Le code doit être conforme ... Et s'il dépasse 2000, il suffit de mettre un TODO en haut en disant que la classe a besoin de travail.
Le pire est le cas contraire lorsque les programmeurs créent trop de minuscules petites classes avec presque aucune fonctionnalité réelle dans chaque classe. Ignorant les conseils de "Favoriser la composition", les programmeurs créent des centaines de classes héritées qui créent des modèles d'objets complexes bien pires que le problème des grandes classes (qui conservent au moins généralement des fonctionnalités avec un nom de classe pertinent).
http://www.Oracle.com/technetwork/Java/javase/documentation/codeconventions-141855.html#304
Il y a trop de lignes de code si la classe fait trop de choses différentes. Essentiellement, si vous suivez le principe de la responsabilité unique pour les classes, il y a une limite à la taille de la classe.
Quant aux limitations physiques que 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 des autres éléments. REMARQUE 2: les attributs sont des constructions de fichiers de classe - à ne pas confondre avec les marqueurs '@Attribute' (c'est-à-dire que les informations de débogage et le code d'octet sont stockés en tant qu'attributs séparés pour une méthode).
- Chaque méthode peut représenter 4 Go (32 bits) de code d'octets généré. REMARQUE: Java antérieures à 1.5 ne pouvaient avoir que 64 Ko (16 bits) de code d'octets généré pour chaque méthode.
En bref, le fichier de classe peut être beaucoup plus volumineux que personne ne jugerait utile. Si vous vous en tenez au principe de responsabilité unique, vos fichiers de classe auront la bonne taille.
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, la plus petite est la règle principale lorsqu'il s'agit de concevoir des classes. Comme pour les fonctions, notre question immédiate est toujours "Comment petit?"
** 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, le nommage est probablement le premier moyen d'aider à déterminer la taille des classes. 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 a de chances d'avoir trop de responsabilités. Par exemple, les noms de classe, y compris les mots de belette comme Processor ou Manager ou Super, font souvent allusion à une malheureuse agrégation de responsabilités.
Alors:
- Assurez-vous simplement que vos méthodes ne font qu'une seule chose.
- Assurez-vous ensuite que la classe n'a pas trop de responsabilités.
Vous vous retrouverez avec une classe d'une taille gérable.
Essayez d'utiliser une meilleure métrique.
Un exemple est le ABC Metric. Il s'agit davantage d'une mesure de la quantité de travail effectuée par le code que de la quantité de code qui existe.
Le nombre de lignes est une mesure assez médiocre pour la qualité de la classe. Pour moi, j'aime regarder (comme d'autres l'ont mentionné) les méthodes publiques, ainsi que toutes les propriétés exposées publiquement (je suppose que les getters/setters publics en Java). Si je devais retirer un numéro de l'air pour savoir quand cela pourrait attirer mon attention, je dirais quand il y en a plus de 10 de chaque. Vraiment, s'il s'agit de plus de 5 propriétés ou méthodes, je vais y jeter un coup d'œil et souvent trouver des moyens de refactoriser, mais tout ce qui dépasse 10 est généralement un signe d'avertissement que quelque chose est assez susceptible d'être mal exposé.
C'est une autre conversation entièrement, mais les méthodes et les champs privés sont moins une odeur pour moi, donc s'ils contribuent beaucoup au nombre de lignes, alors 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 est un joli problème de conception.
Toute ligne qui relève du domaine problématique de votre classe écrite en dehors de la classe est une ligne de trop peu et une de trop dans la classe où elle vit. Considérez une classe comme un sujet. Vous devez le couvrir. Le plus concis possible est idéal, mais s'il faut 500 lignes, il faut 500 lignes. Si 100 de ces lignes couvrent un autre sujet, elles appartiennent ailleurs. Se diviser en sous-domaines plus petits au sein de la classe en tant que classes intérieures est logique, mais je ne définirais ceux en dehors de la classe que s'ils avaient été utilisés ailleurs.