Discussion :

[Invité]

Bonjour.

Je crée ce sujet pour poursuivre une digression qui a eu lieu dans les commentaires de la news sur les commentaires dans un code source.

Celle-ci portait sur la comparaison entre :

• un code découpé en plusieurs fonctions séparées dans des modules/classes distinctes,
• et ce même code laissé en un seul morceau.

Pour rappel, voici les interventions des protagonistes :

Sérieusement, ce qui peut être fautif dans le principe général : "aucune méthode de plus de N lignes", ce ne sont pas les cycles qu'on va perdre mais le fait que 70 lignes de code, s'exécutant de manière séquentielle, dans une seule fonction, sont nettement plus faciles à lire, comprendre, et débuguer que 7 méthodes "uniques mais surement réutilisables un jour, enfin peut être" de 10 lignes, éparpillées dans trois modules distincts, avec des noms qui ne sont pas forcément si évocateurs pris hors contexte.

Et si on applique un peu trop servilement ces principes de découplage (comme avec une application trop naive du principe de responsabilité unique), on se retrouve, dès que le programme devient un peu gros, un peu ancien, avec des verrues, avec ces abominables hiérarchies de classes qui donnent l'impression d'avoir été pensées par un bègue sous acide...

Comme beaucoup d'autres l'ont dit, un code doit rester lisible, et, veut veut pas, il est plus confortable de lire un roman qu'un programme dont vous êtes le héros...

Plus faciles à débugger à la rigueur, plus faciles à lire et comprendre... on ne doit pas vivre dans le même monde. Quand il faut remonter 70 lignes plus haut pour voir à quelle valeur une variable a été initialisée, s'y retrouver dans 4 niveaux de if imbriqués, bref quand il faut que notre cerveau jongle avec des dizaines de symboles plutôt que quelques-uns dans une méthode courte et focalisée, j'ai du mal à voir où est le gain de lisibilité. J'ai toujours considéré comme évident que plusieurs petits problèmes bien découpés étaient plus facilement gérables qu'un gros touffu, mais c'est intéressant de voir que ce n'est pas l'avis de tout le monde.

On ne peut être que d'accord...

Maintenant, si le problème est simple, et que sa solution est bien découpée en un nombre pas trop important de petits morceaux explicites et faciles à comprendre, le code sera facile à comprendre et maintenir, que tu l'aies découpé en petites tranches fines, ou gardé en gros paquets séparés par des commentaires (et des initialisations locales de paramètres, et pas de if imbriqués... ce n'est pas parce qu'on code de grosses fonctions qu'on doit forcément coder illisible, ou idiot). Bref, c'est le pays joyeux des codeurs heureux, des devs gentils, c'est le paradis...

Si maintenant, le problème, ou plutôt sa solution, est compliqué, avec toutes sortes de cas particuliers tordus, qui interréagissent, et des effets de bords - si on est dans la vraie vie, quoi - on fait comment?

Ma sensation, c'est que le découpage en petits bouts ne rendra pas le code plus facile à comprendre. On échange un gros machin difficile, par une collection de petits machins simples, dont on ne comprend plus l'interaction (parce que si c'était facile, on serait dans le cas où le problème ne se pose pas). Et si tous ces éléments sont dispersés dans une collection de modules, et on tout un tas de propriétés que le développeur d'origine a ajouté "des fois que", ça devient vite très compliqué.

Avec ce code délocalisé, il est également beaucoup plus facile de tout casser en ne voyant pas un effet de bord (oui je sais, quand les problèmes sont simples, et bien découpés, cela n'existe pas... mais dans le monde réel...)

Une fois de plus, la caricature de cela, ce sont les hiérarchies de classes démentes, avec plein de petites classes qui font des petites choses minuscules, toutes très faciles à comprendre, mais qui cachent l'organisation générale du traitement effectué.

Ce type d'organisation est séduisante: quand on commence à le lire, on a l'impression de tout comprendre, que tout est simple.... jusqu'au moment où on se demande "comment ca marche", ou "comment le faire évoluer"...

Personnellement, dans le cas d'un traitement compliqué, je préfère nettement avoir une grosse "fonction coeur", avec une documentation éventuellement assez compliquée, et marqué en gros au dessus : "attention code tordu" pour éviter les interventions intempestives, qu'une organisation décentralisée.

Je tiens à lancer le débat : plusieurs fonctions courtes, ou une seule fonction longue ?

A vrai dire, ce débat a déjà une réponse définitive et totalement tranchée, basée sur des éléments totalement objectifs. Et je suis sûr que cette réponse, et ses raisons, en surprendront plus d'un.

Mais je suis curieux de savoir ce que les membres du forum en pensent. Il me semble que la majorité d'entre vous, et surtout ceux qui font de l'OO, privilégieront le choix de plusieurs fonctions courtes.

A vos claviers !

[Invité]

Il est évident que des fonctions courtes (qui tiennent sur un écran à la lecture) sont à privilégier.

Trois raisons principales à cela:

1) le cerveau regarde et comprend ce qu'il a sous les yeux. Comment penser à la ligne qui se trouver 5 écrans plus bas? C'est juste super compliqué. Seul le créateur de ce bazar code en serait capable. Pas facile à maintenir donc pour le collègue.

2) les tests unitaires, vous connaissez? Tester chaque ligne de code afin de valider qu'elle fait bien ce qu'on lui demande. Une petite fonction avec des paramètres en entrée et un résultat attendu. C'est relativement simple à tester. Plus la brique est simple, plus le test unitaire l'est. A la fin on obtient un ensemble cohérent, réalisé à partir de ces éléments.

3) réutilisation du code.


Je crois fermement qu'aucun développeur ne peut soutenir la thèse du code à rallonge. Ou alors, c'est quelqu'un qui n'est pas un professionnel et qui code pour le plaisir.

[el_slapper]

Rien n'est évident.

La facilité à comprendre chaque élément n'a pas forcément de lien avec la capacité à comprendre l'ensemble. Si je surdécoupe comme un malade, évidemment, chaque élément sera facile à comprendre. Mais l'ensemble?

Si un élément n'est pas destiné à être réutilisable, si il appartient naturellement au flux de traitement, si il n'est pas trop grosalors le sortir me parait contre-productif. Et, on peut arriver, dans certains cas, à des listes longues.

Ca n'est pas le cas le plus fréquent. Mais encapsuler les mouches, très peu pour moi.

[cmoicmoi]

On peut aussi réduire le nb de lignes de certaines fonctions en mettant les boucles qui font des petits traitements sur une seule ligne

Quasiment tous ceux à qui je dis ça me prennent pour un fou, et pourtant ... ça améliore nettement la lisibilité globale de la fonction (on voit plus de code d'un seul coup d'œil).

En fait il n'y a pas de règle absolue , ça dépend de la manière dont le cerveau de chacun fonctionne.
Moi je préfère une grande fonction même tarabiscotée à pleins d'appels de classes en cascade avec 3 lignes à chaque fois car ma mémoire de pile est très limitée (je perd facilement le contexte).

En revanche j'ai horreur du code copié collé 3 fois pour faire le même traitement, j'aime bien factoriser.

[gangsoleil]

Reponse de normand (que je ne suis pas) : ca depend. Et non, ce n'est pas du tout tranche.


Pour des fonctionnalites pas trop longues, ou qui demandent un traitement particulier, le decoupage en fonctions est a privilegier. Ainsi, tu peux avoir une fonction d'initialisation, qui va etre decoupee en sous-fonctions comme "lire la conf", "traiter la conf", "initialiser les communications", etc...

Par contre, pour une fonctionalite indivisible du genre "traiter la conf", je ne vois pas l'interet de faire une fonction "je traite le parametre A", puis "je traite le parametre B differemment", puis ainsi de suite.
Je ne vois vraiment pas l'interet du code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
int ma_fonction (parametres)
{
   blabla;
   traitement_1 (blabla);
  blable;
  traitement_2 (blable);
  blabli;
  traitement_3 (blabli)

Et je lui prefere une seule fonction sans sous-fonctions.

Quant a l'argument de l'affichage sur un ecran, je crains qu'il ne faille que vous changiez d'editeurs pour passer sur des outils plus puissants (vim, emacs, eclipse, netbeans, ce que vous voulez) : la plupart proposent de "plier" des parties de code, et de se promener facilement dans le code. Donc les fonctions de moins de 50 lignes, faut un peu oublier.

[micka132]

Il parait que ce n'est pas la taille qui compte, mais la façon de l'on s'en sert.

[Neckara]

Je ne vois vraiment pas l'interet du code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
int ma_fonction (parametres)
{
   blabla;
   traitement_1 (blabla);
  blable;
  traitement_2 (blable);
  blabli;
  traitement_3 (blabli)

Et je lui prefere une seule fonction sans sous-fonctions.

ça dépend, si le traitement_1 fait 10 000 lignes, on sera bien content d'avoir des sous-fonctions .

Quant a l'argument de l'affichage sur un ecran, je crains qu'il ne faille que vous changiez d'editeurs pour passer sur des outils plus puissants (vim, emacs, eclipse, netbeans, ce que vous voulez) : la plupart proposent de "plier" des parties de code, et de se promener facilement dans le code. Donc les fonctions de moins de 50 lignes, faut un peu oublier.

Si on "plie" le code, on a alors plus tout le code sous les yeux.

Il faut aussi se mettre d'accord sur les "fonctions courtes" ou les "fonctions longue", pour moi les "fonctions courtes" auraient 4-5 lignes maximums et les "fonctions longues" auraient une petite 100ène de lignes maximums.

Personnellement, je pense qu'il faut que le découpage soit cohérent, et que le code pouvant être réutilisé doit être dans une fonction.

Si j'ai une fonctions de 3-4 lignes que je réutilise souvent ça me va, mais si je ne l'utilise qu'une seule fois, je pourrais alors peut-être directement copier-coller son code dans la fonction qui l'appelle.

Pour les fonctions "longues", généralement, je n'arrive jamais à faire plus de 50 lignes (qui tiennent aisément sur mon écran).
Si on respecte correctement les principes d'encapsulations et de responsabilité unique, si on découpe les fonctions de manières cohérentes, les fonctions de plus de 50 lignes sont assez rares.
Si on a une très grosse fonction, on peut alors se demander s'il est cohérent de la découper, si une action qui est faite à l'intérieur pourrait être réutilisée, si j'enlève un bout de code pour en faire une fonction, est-ce que mon code devient plus lisible ?

Bref pour moi c'est un peu du cas par cas donc il n'y a pas vraiment de réponses à ce débat, c'est surtout une question de dosage.