L’écriture d’un code qui permet de satisfaire les exigences fonctionnelles et de performance a toujours été la première priorité des développeurs. Au-delà de cet aspect, bon nombre de programmeurs s’attardent un peu sur le style d’écriture de leur code pour faciliter la lecture et la compréhension. Cela permet au développeur de repérer plus facilement les erreurs et également de comprendre ce qu’il essayait de faire lorsqu’il revient sur le projet quelques mois plus tard. Si en plus, d’autres ingénieurs doivent hériter du code, il est généralement conseillé d’adopter un style cohérent qui facilitera la continuité ou la réutilisation du code. L’idée d’adopter un style d’écriture cohérent semble faire l’unanimité, mais une question se pose toutefois sur le style à adopter et à ce niveau, beaucoup de mythes demeurent. Ce qui est accepté par un développeur peut être interdit chez un autre, et ce qui est obligatoire chez l’un peut être inutile chez l’autre. Chacun avance des arguments plus ou moins pertinents pour défendre sa position, et sur Developpez.com, bien qu’on ait plusieurs fois débattu sur ce sujet, on n’a jamais pu arriver à un consensus.
Pour un bloggeur, il y a trop de mythes autour de l’écriture d’un beau code, alors que la règle semble simple : « il n'y a pas de style de code correct, tout comme il n'y a pas de bonne solution à une tâche d'ingénierie », a écrit Marc Newlin. Il pense que les nombreux guides de styles existants écrits dans l’absolu peuvent être utiles, mais manquent souvent de prendre en compte que le contexte d'un projet est aussi important que le code lui-même.
Marc Newlin s’est donc proposé, à travers son billet, de briser ces mythes au sujet de la manière d’écrire un beau code.
Pour lui, c’est une erreur de penser que l’utilisation de commentaires verbeux et d’espaces blancs font de vous un mauvais programmeur. Certains développeurs font valoir que les commentaires sont redondants, mais selon Newlin, c’est peut-être parce qu’ils oublient qu’il est plus facile de comprendre quelques phrases dans notre langue maternelle que le code directement dans un langage. Si ces derniers arrivent facilement à comprendre un code sans commentaire, ils pourraient toutefois gagner du temps à analyser la version commentée. Pour être efficace, le bloggeur pense qu’il est logique de commenter tôt et bien souvent, et les espaces viennent en compléments des commentaires pour faciliter la lecture du code.
Un autre problème auquel il s’attaque est la guerre autour des conventions de nommage. Pour Newlin, « il n’y aura jamais de gagnant, c’est une guerre inutile. Tout le monde a une préférence sur les conventions de nommage, et certains langages préfèrent massivement un style plutôt que l'autre. La seule chose qui importe est la cohérence. »
Ce qu’il propose donc lorsque vous travaillez sur un projet existant, c’est de suivre les conventions déjà en place. Et si vous débutez un nouveau projet, la logique serait de définir les conventions de nommage que vous souhaitez utiliser, et de vous tenir strictement à cela. Dans le cas où vous travaillez sur un projet dans un langage avec un guide de style, « il est bon de suivre les conventions de nommage définies dans le guide », a-t-il écrit.
Vous avez peut-être entendu certains développeurs dire que l’utilisation de bibliothèques tierces est une mauvaise chose. Là encore Marc Newlin pense qu’il s’agit d’une erreur de la part d’un développeur qui aime ressentir la fierté d’avoir écrit un code complexe en seulement 2 jours. Newlin pense que si ce dernier avait avant tout effectué une recherche sur Google, il aurait surement trouvé une bibliothèque sous licence MIT/BSD qui fait exactement ce qu’il veut, sinon mieux. Il aurait alors gagné 2 jours pour améliorer son programme, au lieu d’essayer d’avoir la propriété complète sur son code.
Pour Marc Newlin, le plus important, c’est d’écrire votre code de sorte qu’un étudiant en informatique de première année puisse le lire, un beau code se doit d’être simple. Il ajoute également qu’un programmeur éclairé va chercher à être plus productif en étant assez humble pour utiliser des bibliothèques tierces si possible. Cela lui éviterait d’écrire beaucoup. Il devrait également utiliser le plus de commentaires possibles.
Source : Blog de Marc Newlin
Et vous ?
Partagez-vous les points de vue de Marc Newlin ? Qu'est ce qui caractérise un beau code selon vous ? 
Envoyé par Sicyons
