Quand on code avec les pieds…
20 septembre 2011 Un commentaire
OpenSSL est un bon exemple: http://corte.si/posts/code/reading-code.html
Codé à l’ancienne, avec des Goto, une mauvaise indentation, aucune convention de nommage: parfois en camel case, parfois avec des underscores, le nom de la fonction est mal nommée (avoué dans le code source en le commentaire dans l’en-tête). Bref, de la belle merde. Pour participer à ce projet il faut vraiment le vouloir. Déjà quand j’écris des bugfix pour un logiciel dont le style de codage ne me plait pas (en particulier la position des accolades), cela m’insupporte. Moi je code comme ceci:
if (cond) {
instr...
} else {
instr...
}
certains comme cela:
if (cond)
{
instr...
}
else
{
instr...
}
8 lignes au lieu de 6, seulement 2 de plus, mais visuellement je n’aime pas. La raison que je trouve généralement pour le second style est que cela permet de mieux voir quand le code est indenté, mais quand on fouille un peu plus c’est une habitude de la faculté/école où on leur faisait faire ça pour qu’ils se trompent moins. Peut-être car sur du papier il n’y a pas la coloration syntaxique, mais sinon « if » et « else » sont colorés et le code est parfaitement compréhensible. Je dirai même que dans le premier style d’écriture, on distingue mieux les deux blocs de code. Mais bon, chacun ses goûts.
Pour OpenSSL c’est carrément une absence totale de structure et de cohérence. Le mélange camel case et underscore… ça me rappelle PHP, en PHP il y a str_replace() par exemple, qui utilise un underscore, mais strlen(), ou strpos() qui en n’utilise pas (et qui ne sont ni en camel case au passage). Il y a html_ entity_decode() et htmlentities()… pour en voir d’autres c’est ici. Ce n’est pas pratique pour coder mais heureusement qu’un bon éditeur de code propose l’auto-complétion, cela ne supprime toutefois pas l’incohérence et empêche d’écrire une fonction sans douter (sans parfois devoir faire une recherche, ou sans attendre l’auto-complétion).
Puis il y en a qui sont fermé dans une idéologie qu’ils ne remettront jamais en question: que ce soit dans le monde du travail ou open source. Par exemple en javascript, pour créer de nouveaux éléments dans le DOM on peut soit utiliser innerHTML, soit créer les éléments à la main avec createElement(). Il y a des personnes qui s’emmerdent la vie à utiliser createElement() et appendChild() pour former le DOM seulement par principe. Car innerHTML a été mis en place par Microsoft de manière non standard, et c’est du coup souvent déprécié. Leur coté anti-microsoft les poussent à se pourrir la vie alors qu’ils pourraient se la simplifier. A noter que la fonction magique de jQuery, appelé html(), utilise innerHTML…
Un récent projet open source que j’ai regardé (jquery.multifile), possède une indentation non uniforme. Parfois des tabulations, parfois des espaces, parfois les deux, parfois un seul espace (pour un niveau d’indentation), parfois plusieurs espaces (toujours pour un niveau d’indentation). Outch, heureusement qu’il existe des programmes pour remettre tout en forme. Par contre, il n’existe aucun programme pour simplifier la logique d’un code source… ce serait trop facile.
L’idéologie, ou les principes, peu importe comment on appelle ça, peut conduire les personnes à faire des choses compliquées… et cela inconsciemment même, je vous laisse imaginer le résultat dans un projet open source, sans vraiment de structure, sans assurance qualité, et ou chacun est libre de faire n’importe quoi. Au final, ça marche… ou pas, les gens en ont marre de patcher OpenSSL et cherchent une alternative: GnuTLS, cryptlib, etc.