Temps de lecture : 0 Minutes

Graisse de classe | Pourquoi devrait-il être mesuré

Quelle est la taille de votre classe ? – Quelle est la taille trop grande?

Pour quiconque écrit le code, il y a eu cette préoccupation – quelle devrait être la taille idéale de mon code dans une classe/méthode/fonction.

Cela diffère de chaque développeur. En règle générale sur 30, Steve McConnell dans son livre, Code Complete dit que,

Si un élément est composé de plus de 30 sous-éléments, il est fort probable qu’il y ait un problème sérieux :

a) Les méthodes ne doivent pas comporter plus de 30 lignes de code en moyenne (sans compter les interlignes et les commentaires).

b) Une classe doit contenir en moyenne moins de 30 méthodes, ce qui donne jusqu’à 900 lignes de code.

c) Un package ne doit pas contenir plus de 30 classes, comprenant ainsi jusqu’à 27 000 lignes de code.

Des études montrent que le nombre de lignes de code est la base sur laquelle reposent la qualité et la complexité du logiciel que vous construisez. La valeur réelle d’une directive telle que la règle de 30 réside dans le fait que vous examinez le code et identifiez les risques et les coûts.

Trop de lignes de code seront difficiles à compiler et à tester. Cependant, il n’y a pas de métrique idéale qui mesure le gras de la classe. Ce n’est pas seulement basé sur “l’opinion”, c’est basé sur le résultat de décennies de pratique. Les revues de code aident à identifier et à corriger les problèmes dans la base de code.

Les examens informels peuvent trouver 20 %-30% défauts de code. Des études chez IBM, HP, Microsoft et d’autres endroits montrent qu’il est plusieurs fois moins cher de trouver des bogues dans les revues de code que par des tests. Et les preuves continuent d’affluer pour confirmer que les revues de code fonctionnent.

Horus, une plate-forme de gestion de l’ingénierie permet de revoir les lignes de code en cours d’écriture et ce que cela signifie pour les développeurs qui l’écrivent, les risques et les coûts associés à la direction intermédiaire et supérieure, quel que soit le domaine, le niveau de maturité de l’organisation, ou phase du cycle de vie au cours de laquelle ils ont été appliqués.

En savoir plus sur Horus dans l’ article précédent.

Lire aussi Complexité cyclomatique

Keerthi Veerappan

An INFJ personality wielding brevity in speech and writing. Marketer @ Zucisystems.

Partagez ce blog, choisissez votre plateforme !

Leave A Comment

Articles Similaires