Combien de lignes de code sont trop nombreuses ?

Question

Une chose qui me rend parfois fou est de lire les fonctions d'une autre personne qui s'étendent sur 5 longueurs de moniteur vertical, ou des fichiers .cpp qui font plus de 2000 lignes. Pour une meilleure lisibilité, ne serait-il pas préférable de diviser une fonction de 1000 lignes en plusieurs sous-fonctions plus petites appelées par une seule fonction ? L'implémentation d'une classe ne devrait-elle pas s'étendre sur un nombre démesuré de lignes ? Quand faut-il commencer à décomposer une fonctionnalité en sous-classes ou en classes utilitaires ?

Est-il déraisonnable pour moi d'être ainsi rebuté par des fichiers/fonctions excessivement volumineux ? Et, si je ne suis pas dans l'erreur, comment dois-je aborder un collègue pour le convaincre de remanier son code ?

Edit : Il y a beaucoup de bonnes réponses à cette question, et je devrais me documenter sur le sujet. Code complet chapitre. Pour ce qui est de convaincre mon ou mes collègues, il me semble un peu trop coûteux de leur faire remanier le code de production existant, mais je me contenterais que tout leur code futur soit bien remanié.

Answer 1

Facile. Si la méthode fait plus d'une chose définissable, elle est trop longue ;-)

Answer 2

Eh bien, pour jouer l'avocat du diable :

Une fonction de 1000 lignes est-elle meilleure ou pire que 1000 fonctions d'une ligne qui donneront 4000 lignes de code si l'on tient compte de l'overhead supplémentaire pour la définition de la fonction ?

En général, les fonctions doivent être petites. Quelqu'un - j'ai oublié qui - a mis en place des conventions de codage, et l'un des conseils était : Le nom de la fonction doit définir tout ce que fait la fonction. GetUserName(), IncrementPostCount() etc. Pas le comment, juste le "quoi", c'est-à-dire le résultat de la fonction, mais cela s'applique également aux fonctions privées.

Si vous avez du mal à nommer votre fonction ou si vous vous retrouvez avec "AddOrDeleteOrUpdateOrMoveOrPromoteUser()", c'est un signe évident : Votre fonction est trop longue. De même, si vous avez des fonctions super-génériques comme ManageDatabase() ou CrashWallStreet(), c'est le signe que la fonction doit être remaniée.

Une fonction de 1000 lignes est très probablement trop longue, mais il y a toujours des situations où vous ne pouvez pas diviser une fonction, car tout le code appartient essentiellement à une tâche, et cette tâche est spécifiée dans le nom de la fonction.

Mais j'ai trouvé que la règle "Si vous ne pouvez pas donner un nom correct à votre fonction, elle doit être remaniée" était vraiment bonne.

Answer 3

En fait, je pense que le code complet dit "plus d'un écran est trop long" (pour les méthodes en tout cas).

Answer 4

Il devrait être remanié si...

• Il fait plus d'une chose.
• Il fait cette seule chose plus d'une fois, en dehors d'une boucle.
• Si tu oublies la première ligne, le temps que tu lises la dernière.

Answer 5

De Le journal d'Ovide :

J'ai récemment écrit du code pour Class::Sniff qui détecterait les "longues méthodes" et les signalerait comme une odeur de code. J'ai même écrit un article de blog sur la façon dont j'ai fait cela (quelle surprise, hein ?). C'est alors que Ben Tilly a posé une question d'une évidence embarrassante : comment puis-je savoir que les longues méthodes sont une odeur de code ?

J'ai sorti les justifications habituelles, mais il ne voulait pas lâcher prise. Il voulait des informations et il a cité l'excellent livre Code Complete comme contre-argument. J'ai pris mon exemplaire de ce livre et j'ai commencé à lire "How Long Should A Routine Be" (page 175, deuxième édition). L'auteur, Steve McConnell, soutient que les routines ne devraient pas dépasser 200 lignes. Bon sang ! C'est beaucoup trop long. Si une routine dépasse 20 ou 30 lignes, je pense qu'il est temps de la diviser.

Malheureusement, McConnell a le culot de citer six études distinctes, qui ont toutes montré que les routines plus longues non seulement ne sont pas corrélées à un taux de défectuosité plus élevé, mais qu'elles sont aussi souvent moins coûteuses à développer et plus faciles à comprendre. En conséquence, la dernière version de Class::Sniff sur github documente maintenant que les routines plus longues peuvent ne pas être une odeur de code après tout. Ben avait raison. J'avais tort.