En fait plus concis ne signifie pas forcément plus clair. Ca peut l'être, mais ça peut aussi être tout l'inverse. Pour le développeur en particulier, c'est clair que plus y a de touches à taper, plus c'est chiant. Par contre pour un relecteur, un nouveau mainteneur, ou même le développeur lui-même mais 3 mois après quand il revient sur du code qu'il a écrit pour le changer et s'en rappelle plus, des fois c'est chiant si on comprend pas tout de suite ce que le développeur a voulu faire.

Un exemple (parmi tant d'autres) très simple de ce qu'apporte la verbosité est les paramètres labellisés/nommés par ex. C'est un système que je n'ai vu que sur Ocaml et Ada95, mais je ne connais pas tous les langages du monde et ça existe sûrement ailleurs.

Par exemple, imaginez la fonction "attaque" qui prend 2 paramètres: l'attaquant et l'attaqué. Comment savoir si le premier paramètre est l'attaquant ou l'attaqué, surtout que les 2 params ont le même type (un "personnage")? Dans notre cas, sémantiquement nous ferons souvent plutôt: attaque (attaquant, attaqué). Néanmoins il y a de nombreux cas de fonctions où ce n'est pas si évident (et même là, après tout rien n'interdit à un dév d'estimer que c'est mieux dans l'autre sens!). Donc si on lit le script suivant: attaque (robert, martin). Qui attaque qui? Simple et concis, c'est sûr; clair, sûrement pas. On se reporte à la doc, on perd du temps. Et là c'est un exemple facile, encore une fois (quand t'as une fonction avec 10 paramètres et une sémantique beaucoup moins "vie courante", y a plus rien de clair). Mais les langages qui implémente le nommage de variables donnent la possibilité d'écrire:

attaque (attaquant => robert, attaqué => martin).

Là, c'est réellement clair. Et pourtant c'est sacrément plus verbeux. Mais au moins n'importe quel pecno qui relit le code le comprend immédiatement et on gagne un temps fou.

Donc non concis n'implique absolument pas clair, encore moins réciproquement.

[ Répondre ]