./79> Tu continues à y être sensible donc ? Perso ce serait plutôt le contraire alors. C'est non sans nostalgie que ces théories me replongent dans le temps où j'étais à l'école, mais depuis je bosse dans une équipe où on est une vingtaine de dévs et la réflexion a passablement changé.
En particulier l'OO à tout prix c'est fini. Désormais j'ai tendance à dire que la complexité du code (~lignes de code + nombre de classes) devrait être proportionnelle à l'importance "business" du morceau de code. S'il s'agit du coeur du système ou que d'une façon générale on ne peut que trop insister sur l'importance de maîtriser la partie en question avant d'y apporter toute modification, alors on peut y aller franchement sur les classes, la maintenabilité et tout. Si par contre il s'agit d'une petite partie qui sera peu revisitée, qui ne devrait pas l'être ou qui n'est pas mature, alors mieux vaut parfois écrire un code naïf. C'est (peut-être) moins beau (car la beauté d'un code c'est aussi la fierté qu'on peut en tirer ), moins maintenable mais au moins n'importe qui peut le comprendre, saisir les effets de bord voire le réécrire en partie s'il ne convient plus au besoin changé.
C'est marrant parce qu'académiquement je dois donc être devenu un moins bon programmeur, pourtant je trouve le résultat bien meilleur. Mais en tous cas c'est pour cette raison que je ne choisirais pas ton langage Onur