Pourquoi c'était mieux avant... Les fonctions kilométrique
par
, 19/01/2015 à 11h35 (1376 Affichages)
Quand on recherche la "perfection" ou les "standards" actuels, il est souvent question de la fonction kilométrique et pourquoi celle-ci est le "mal". Pour deux raisons :
- La complexité cyclomatique.
- Les fonctions trop long (Screen wide function)
Archéologie :
Je fais l'expérience actuellement d'un langage (NSDK) relativement vieux avec son IDE tout aussi vieux. Et forcé de constater que les standards actuels seraient un enfer si ils étaient appliqués.
Cela est principalement dû à une fonctionnalité qui n'est pas présente dans l'IDE : "Aller/Retour à la déclaration de la fonction" / "Trouver les appels"... (Du moins, pas au point de pouvoir naviguer dans le code facilement.)
Et cela change tout, car si tu ne sais pas où cette fonction ou sous-fonction se trouve, tu va devoir faire une recherche dans tout le projet, à l'ancienne. Ce qui réduit considérablement accessibilité de celle-ci. Il n'est plus question de faire une sous fonction pour le if spécifique à la fonction ! En particulier si celui-ci est compliqué...
Il n'empêche qu'il est nécessaire d'avoir des fonctions bien séparées pour chaque traitement. Mais si celle-ci fait 250 lignes et a 3 niveaux de if, ce n'est pas grave, si cela est pour éviter d'avoir à se "battre" avec l'IDE pour retrouver le code.
Aujourd'hui :
Dans nos écoles d'ingénieurs et de développeurs, on nous apprends ces règles et pourquoi on les appliques. Cependant, je constate qu'on applique ces normes et bonnes pratiques souvent pour les appliquer et non pour en tiré un bénéfice. Ce qui est dommageable, car le métier du développeur n'est pas simplement d'appliquer des règles.
Faire 5 sous-fonctions post-fixé 1/2/3/4/5, cela fait plaisir au sonar, mais cela n'a strictement rien d'une bonne pratique, tout comme le fait de crée trop de fonction. (C'est le cas quand celle-ci n'ont plus de sens fonctionnel. Et oui, j'ai déjà vue des 1/2/3/4/5 en production sur des traitements majeurs.) En effet, beaucoup d'entre nous les appliques "à l'aveugle". Car "c'est les bonnes pratiques" ou pour faire plaisir au Sonar/CheckStyle ou autre outils. En cela, c'était mieux avant.
Conclusion : vers le future et au-delà
Les bonnes pratiques évoluent avec les outils et les langages. Il est peu probable que celles-ci soient les mêmes dans 15 ans. Mais, pour beaucoup, nous seront encore là. Je fait partie de la "jeune" génération à qui on a martelé ces règles, normes et bonnes pratiques. J'espère honnêtement que nous aurons la sagesse de remettre en cause celles-ci quand cela sera nécessaire.
- Dans le cas "limite", de la fonction qui fait 121 lignes à la place de 120 lignes et que dans ce cas précis, c'est normalement.
- Dans quelques années, quand la "bonne" pratique bidule ne sera plus d'actualité à cause de tel ou tel évolution.
Pendant la réalisation de ce billet, j'ai cherché un peu ce qui parlait spécifiquement de la méthode trop longue. Il y a un certains nombre d'avis qui va "contre" la règle établie "une méthode ne doit pas faire plus de X lignes". Et qu'on a aujourd'hui aucune preuve irréfutable que les petites méthodes sont mieux (On n'a pas l'inverse non plus.)Envoyé par Moi (maintenant)
Que pensez-vous des fonctions kilométriques ?
Appliquez vous les règles/normes/conventions ? Si oui, avez vous des "exceptions" ?
Avis intéressants sur la question, trié par ordre d'intérêt (le mien en tout cas):
Note : Je vous encourage vivement à allez lire le premier lien. Celui-ci me semble le plus intéressant. Car, il n'a pas un point de vue arrêté sur la question. Il est probablement plus pertinent que ce que je dis...
http://dubroy.com/blog/method-length...ctually-worse/
http://c2.com/cgi/wiki?LongFunctionHeresy
http://www.javacodegeeks.com/2012/12...m-too-big.html
http://programmers.stackexchange.com...n-7-statements
http://stackoverflow.com/a/475762/4338165
Épilogue :
Quand je vois le nombre d'affichage (40+) de mon dernière billets, je suis très touché. Cela me fait énormément plaisir. J'écris pour partager mon avis et avoir le votre sur le sujet ! D'ailleurs, l'un de mes billets en cours à comme sujet les blogs intéressants en informatique. Et l'un d'eux, un blog, avec beaucoup de visiteur et de commentateurs, avait pour sujet "les gens ne lisent pas tout". Et ils ont fait le "teste de la banane". Celui-ci consiste à notifier les commentateurs au milieu du billet que si ils ajoutent un commentaire ceux-ci doivent ajouter le mot banane à leur commentaire, pour indiquer qu'ils ont bien lu l'ensemble du billet sur 98 commentaires, pas une seule banane ! Alors, vous avez la banane vous ?
Cordialement,
Patrick Kolodziejczyk.