Il me fait aussi penser à une autre source de complexité, qui est la tendance de certains à écrire plein de petites fonctions, même si le graphe d'appels est extrêmement simple et ne justifie pas de découper en plusieurs fonctions. Du coup au lieu de lire de haut en bas une fonction de 50 ou 100 lignes, on doit se promener dans un plat de spaghettis.
J'en avais parlé à un collègue qui avait ce travers, et il m'avait dit que c'était une recommandation du livre "Clean code" de faire des fonction très courtes, de quelques lignes seulement. Je ne sais pas si c'est vrai (je n'ai pas lu le livre). La recommandation du Coding Style du noyau Linux me semble faire plus de sens: https://www.kernel.org/doc/html/v4.10/process/coding-style.html#functions
# et les fonctions
Posté par Lucas . En réponse au journal Software architecture considered harmful. Évalué à 8.
ton journal me fait penser au https://en.wikipedia.org/wiki/Code_golf
Il me fait aussi penser à une autre source de complexité, qui est la tendance de certains à écrire plein de petites fonctions, même si le graphe d'appels est extrêmement simple et ne justifie pas de découper en plusieurs fonctions. Du coup au lieu de lire de haut en bas une fonction de 50 ou 100 lignes, on doit se promener dans un plat de spaghettis.
J'en avais parlé à un collègue qui avait ce travers, et il m'avait dit que c'était une recommandation du livre "Clean code" de faire des fonction très courtes, de quelques lignes seulement. Je ne sais pas si c'est vrai (je n'ai pas lu le livre). La recommandation du Coding Style du noyau Linux me semble faire plus de sens: https://www.kernel.org/doc/html/v4.10/process/coding-style.html#functions