KISS

Keep it Simple, Stupid ou pourquoi faire compliqué quand on peut faire simple. Pour un problème donné, il existe un risque de se compliquer la vie, cela peut-être dû à une mauvaise compréhension du problème ou à une mauvaise connaissance du langage. C'est par exemple, ajouter une possibilité inutile et compliquée à un logiciel puis se rendre compte que ça ne sert à pas grand chose. C'est aussi passer plusieurs heures à coder une fonction qui existe déjà ou s'embêter à formater des chaines puis découvrir la fonction sprintf().

write code that scales well

J'avais lu ça dans les offres d'emploi Last.fm et cela signifie -pour moi- écrire un code qui puisse se mettre à l'échelle, autrement dit un code qui convienne pour traiter un fichier ou 100, cela se fait en écrivant un code dynamique : au lieu de coder en dur toutes les variables, on code une fonction qui s'adapte aux paramètres qu'on lui donne. Cela permet de recycler le code dans un autre contexte avec peu ou pas de modifications.

Commenter son code

Un code bien documenté peut être transféré à quelqu'un d'autre ou tout simplement être maintenu plus facilement dans le temps par son créateur : est-ce que dans 6 mois on se souviendra que la fonction plop() permet d'ajouter des lettres au hasard. Ne pas comprendre son propre code, ça fait une drôle d'impression : le code fonctionne, mais on ne sait pas comment ! Il devient alors beaucoup plus fastidieux de corriger un bug quand on doit ré-apprendre comment s'organise le tout. Surtout quand entre temps on a développé une autre logique de programmation.

Coder proprement

Un code propre est d'abord un code bien lisible : aéré et bien organisé. Les lignes de code qui réalisent une même action sont rassemblés en un bloc, les blocs sont séparés entre eux. Les blocs d'instruction sont indentés à différents niveaux suivant leur position. Cela s'applique aussi au (X)HTML. Les variables portent des noms qui ont un sens, et pas seulement au moment de la conception pour le développeur.

Conclusion

Bref, vous l'aurez compris, les principes c'est bien, mais ça ne sert à rien si on ne les respecte pas. Et pourtant si on les respecte dés le début on gagne du temps au fur du développement d'un logiciel. Ne respecter aucun de ces principes aboutit à un code compliqué, inadapté à une nouvelle utilisation, difficile à maintenir et illisible. Avec ça et la Loi de Murphy : si il y a un risque que ça ne fonctionne pas, alors ça ne fonctionnera pas, bonjour le cocktail explosif !

Edit : j'avais oublié, la seule vraie philosophie de développement est La Rache.