Ce qui se conçoit bien s'énonce clairement !
Ya pas à dire, l'informatique, c'est comme la littérature.
Il y a les gens qui savent écrire et il y a les autres. Il y a les gens qui savent se faire comprendre du premier code source et il y a les autres.
Il est très important de savoir écrire correctement pour se faire bien comprendre. Tout comme il est plus facile de lire du Voltaire que du Kant, il est aussi plus facile de lire du source postfix que du source sendmail, plus facile de lire du source noyau que du source xorg.
Et ne parlons pas des rfc et autres howto. Il est plus facile de lire la RFC sur IP que la RFC sur punycode.
Les points à réfléchir lorsque vous écrivez :
- la prédictibilité : des noms de fonction, des types de paramètres, de l'ordre des paramètres
- la lisibilité : nommage ni trop court ni trop long, ni trop proche (si un seul caractère diffère entre 2 noms, les fonctions doivent être identiques à l'exception d'un paramètre par exemple)
- la mémorisabilité : découper son texte en concepts indépendants (l'orienté objet a fait beaucoup pour ça)
- la compréhensibilité : avoir des blocs suffisamment courts pour les lire et les comprendre dans leur globalité
- la visualisabilité : faites un schéma avant d'écrire, ça sera clair dans votre tête et donc dans celle du lecteur, si c'est trop dur, incluez votre schéma.
Avoir du style, ça se travaille, et ça nécessite de la réflexion, on ne jette pas une api sur l'écran au fil de l'eau. On écrit ce qu'on pense bien, on l'utilise, puis on constate les problèmes, on la refait, et on renomme toutes les fonctions pour respecter une certaine cohérence.
Bon, excusez-moi, cet article est un peu jeté en vrac comme ça et n'a pas vraiment de style.
Comments