Les méthodes longues sont mauvaises pour plusieurs raisons :
Comment convaincre vos collègues développeurs d'écrire des méthodes courtes ? (les armes sont interdites =)
question de développeur agile
Cela dépend de vos définitions de "court" et "long".
Quand j'entends quelqu'un dire "écrivez des méthodes courtes", je réagis immédiatement mal car j'ai rencontré trop de spaghettis écrits par des gens qui pensent que la méthode idéale fait deux lignes : Une ligne pour faire la plus petite unité de travail possible, suivie d'une ligne pour appeler une autre méthode. (Vous dites que les longues méthodes sont mauvaises parce qu'elles sont "difficiles à comprendre" ? Essayez d'entrer dans un projet où chaque action triviale génère une pile d'appels de 50 méthodes de profondeur et essayez de comprendre laquelle de ces 50 couches est celle que vous devez changer...)
En revanche, si, par "court", vous entendez "autonome et limité à une seule fonction conceptuelle", alors je suis tout à fait d'accord. Mais n'oubliez pas que cela ne peut pas être mesuré simplement par des lignes de code.
Et, comme Tydok l'a fait remarquer, on attrape plus de mouches avec du miel qu'avec du vinaigre. Essayez de leur dire pourquoi votre façon de faire est bonne au lieu de leur dire pourquoi leur façon de faire est mauvaise. Si vous pouvez le faire sans faire de comparaisons ou de références ouvertes à eux ou à leurs pratiques (à moins qu'ils ne demandent spécifiquement comment vos idées pourraient être liées à quelque chose qu'ils font), cela fonctionnera encore mieux.
Je suis d'accord. Les piles d'appels massives devraient certainement entrer dans la discussion.
N'est-ce pas ce qui tient dans un seul écran qui est "court" ? Mais bon, il m'arrive d'utiliser Consolas à une taille incroyablement petite avec l'écran tourné de 90 degrés... :) Quoi qu'il en soit, c'est le test unitaire qui définit le mieux ce qui est court. Si vous ne pouvez pas facilement écrire un test unitaire pour une méthode, c'est qu'elle est trop longue ;)
La différence entre court et long est une question de "je le sais quand je le vois". Mais lorsque je vois une méthode de 400 lignes avec un indice McCabe de 40+, elle est considérée comme "longue".
D'après mon expérience, le meilleur moyen de convaincre un pair dans ces cas-là, c'est l'exemple. Trouvez des occasions de leur montrer votre code et discutez avec eux des avantages des fonctions courtes par rapport aux fonctions longues. Ils finiront par comprendre spontanément ce qui est mieux, sans que vous ayez besoin de leur donner l'impression d'être de "mauvais" programmeurs.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
Bonne question... Je me demandais la même chose :)