IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

Un bon développeur est un développeur flemmard !

Pourquoi c'était mieux avant... Les fonctions kilométrique

Noter ce billet
par , 19/01/2015 à 12h35 (1354 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.


Citation Envoyé par Moi (maintenant)
Le pourquoi est plus important que le comment.
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.)

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.

Envoyer le billet « Pourquoi c'était mieux avant... Les fonctions kilométrique » dans le blog Viadeo Envoyer le billet « Pourquoi c'était mieux avant... Les fonctions kilométrique » dans le blog Twitter Envoyer le billet « Pourquoi c'était mieux avant... Les fonctions kilométrique » dans le blog Google Envoyer le billet « Pourquoi c'était mieux avant... Les fonctions kilométrique » dans le blog Facebook Envoyer le billet « Pourquoi c'était mieux avant... Les fonctions kilométrique » dans le blog Digg Envoyer le billet « Pourquoi c'était mieux avant... Les fonctions kilométrique » dans le blog Delicious Envoyer le billet « Pourquoi c'était mieux avant... Les fonctions kilométrique » dans le blog MySpace Envoyer le billet « Pourquoi c'était mieux avant... Les fonctions kilométrique » dans le blog Yahoo

Catégories
Sans catégorie

Commentaires

  1. Avatar de ego
    • |
    • permalink
    Bon on commence par la fin ....banane !!

    Ben tu as raison dans le sens où la taille n'a pas forcément d'importance
    il faut s'attacher à la cohésion aussi, autre critère d'importance. Et le découpage est plus lié à une éventuelle reutilisabilité ou à une meilleure lisibilité ou séparation des tâches.
    Et donc pas de taille prédéfinie...
  2. Avatar de kolodz
    • |
    • permalink
    Merci pour ton message !
  3. Avatar de ALT
    • |
    • permalink
    Pareil : je suis d'accord avec Ego : le découpage en petits tronçons permet une meilleure lisibilité du code (pas facile de s'y retrouver dans un bloc [fonction, procédure, méthode...) de deux cents lignes !
    En le coupant en petites unités logiques, on le rend plus digeste. Et, donc, plus maintenable aussi.
    Néanmoins, je pense aussi qu'il n'y a pas de dimension idéale ; ça dépend du code : il vaut mieux parfois un bloc homogène de cinquante lignes que deux blocs plus petits mais dont le découpage n'a pas d'autre logique que de limiter la longueur dudit bloc.

    Conclusion : vivent les blocs courts, mais pas de limite précise quant à leur longueur maximale. Na !