Triabulle

J’ai fait un constat : le code pue. Sinon, pourquoi est-ce que l’on s’efforce toujours d’en écrire le moins possible? On préfère tous lire du code clair et concis qui exprime uniquement le nécessaire, on reconnait l’importance de diviser son code en petites méthodes jusqu’à temps que chacune d’elle ait un rôle qui soit bien défini… on aime répartir la puanteur de notre code sur une plus grande surface. Ça sent moins comme ça.

Une des choses que je déteste le plus aujourd’hui, c’est de voir une fonction qui tente d’accomplir plusieurs choses en même temps. En fait, presque tous les programmeurs ont une nausée subite lorsqu’ils apperçoivent du code de la sorte :

Les gens qui codent de cette façon ne se rendent pas compte qu’ils sont en train de créer un monstre… un monstre qui se chargera de pourrir la vie du futur programmeur qui aura à apporter une modification dans cet horrible code. Chaque petite parcelle de savoir aurait dû avoir sa propre fonction… même si cela peut paraître exagéré. J’ai traduit l’expression “parcelle de savoir” directement de l’anglais “piece of knowledge”. Ce n’est pas le mot le plus viril au monde, mais c’est parce que je m’efforce de ne pas utiliser trop d’anglicismes.

Pour ceux qui ignorent de quoi je parle, voici ma définition personnelle de parcelle de savoir (ou piece of knowledge) : Un ensemble de lignes de code partageant un sujet commun et ne pouvant pas être dissociées les unes des autres.

Les frameworks MVC poussent le concept de “petites méthodes” encore plus loin. Avec Ruby on Rails par exemple, si nous avons un contrôleur du nom de recettes, les méthodes contenues dans ce contrôleur seront directement équivalentes à ce que l’on retrouvera dans la barre d’adresse. Par exemple, si le contrôleur recettes possède une méthode du nom de voir, cela annonce que nous aurons une adresse URL du genre : geccoe.ca/recettes/voir/trempette-aux-epinards. Avec ce fonctionnement, les méthodes sont automatiquement bien définies. Que pourrait faire la méthode “voir” autre que de préparer le terrain pour VOIR une recette? Pas grand chose! C’est d’ailleurs pour cette raison que la méthode “voir” ne possède en réalité que 3 ou 4 lignes. De plus, une des philosophies derrière Ruby est justement de monter ses applications en créant une multitude de fonctions minuscules et hyper ciblées. Je crois que l’inventeur de Ruby a compris mieux que tout le monde le fait que le code dégageait une odeur nauséabonde et qu’il fallait absolument remédier à ce fléau.

Il en est donc arrivé avec le plan de match suivant lors de la création de son langage :

1) Inventer une syntaxe moins puante se rapprochant du langage humain et qui permet d’accomplir une seule chose de plusieurs façons afin que le programmeur puisse s’exprimer librement.

2) Prôner l’art de répartir la puanteur du code sur une plus grande surface.

Je respecte et j’approuve cette philosphie complètement. Depuis que je code en Ruby, je n’ai même plus besoin de vaporiser du Febreeze dans mon bureau pour chasser les mauvaises odeurs de mon code.