1. Planifiez l'extensibilité

Quand on fait un programme, c'est pour résoudre un problème particulier. Vous pouvez réaliser ce programme rapidement en vous concentrant sur cet unique problème. Cela va fonctionner. Mais ça va pas durer. Tout programme est amené à évoluer et si vous ne l'avez pas pensé pour être extensible, votre code va devenir de plus en plus difficile à intégrer au projet et de plus en plus inmaintenable (oui, je sais c'est pas français, mais j'ai pas trouvé de meilleur terme).

Il faut toujours garder en tête que les choses évoluent et donc coder en perspective du changement.

La partie maintenance est la plus grosse partie de la vie d'un logiciel. Développez donc un code facilement maintenable.

Note: Cependant, vous devez également garder le principe KISS en tête et ne pas penser trop loin dans les possibilités hypothétiques de votre logiciel.

2. N'utilisez pas de nombres magiques

Les nombres magiques sont des nombres hard-codés dans le code. Ces nombres rendent le code plus difficile à lire (et donc à comprendre et débugger). Ces nombres doivent être remplacer par des constantes ou des enum (préférable).



est plus difficile à lire que



permet également de pouvoir changer cette valeur sans parcourir tout le code pour modifier les références. Par exemple, si on veut rajouter un niveau de droit à notre application, les administrateurs auront le niveau 4. Il est plus simple de juste modifier la valeur de la constante ADMIN que de parcourir tout le code à la recherche du nombre 3 pour le remplacer par un 4, au risque d'en oublier ou de remplacer de mauvais nombres.

Note: Personnellement, j'utilise des enum avec des valeurs qui sont 2n ce qui permet de faire des combinaisons pour une fonction de recherche (par exemple).

Reprenons notre exemple des niveaux des utilsateurs.



L'appel de la méthode getUsers(3); getUsers(Normal + AdminLocal); nous renvois, comme vous l'avez deviné, la liste des utilisateurs normaux et des administrateurs locaux.

3. Commentez le pourquoi, pas le comment

Certains programmeurs s'obstinent à mettre en commentaire la version textuelle de leur code. Des commentaires du genre



sont légions dans beaucoup de programmes. Ce genre de commentaire est totalement inutile. Le code en lui même est suffisamment clair.

Les seuls endroits où les commentaires du comment sont utiles sont pour décrire les différentes étapes d'un algorithme pas spécialement trivial et sont la plupart du temps mis en entête du bloc englobant l'algorithme (d'habitude une fonction).
Par contre, il convient de documenter pourquoi vous faites certaines opérations dans votre code.

Note: La plus part du temps, si votre code est clair et vos variables bien nommées, vous n'avez pas besoin de commentaires.

D'un point de vue personnel, je formate mes commentaires pour qu'ils soient compris par doxygen.

Il est également judicieux de noter en commentaire l'url où on a trouvé un bout de code (cfr. point suivant) ou, si vous utilisé un bugtracker, de compléter votre commentaire pourquoi avec le numéro du bug (ou de la feature).

4. Ne réinventez pas la roue

Les développeurs OO sont souvent tentés d'écrire leurs propres classes pour réaliser des choses qui ont déjà été faites plein de fois. L'exemple classique est la gestion des conteneurs (vecteur, liste, pile, file...). Pourquoi perdre du temps dans l'implémentation, le débugguage et l'optimisation de quelque chose qui a déjà été fait par quelqu'un d'autre. En C++, il y a la stl et la fabuleuse boost. Elle ne sont pas des plus faciles à comprendre et à utiliser pour les jeunes programmeurs mais au moins, on est sûr d'avoir quelque chose de fonctionnel. De plus si une autre personne doit lire/debugguer votre code, il n'a pas à apprendre comment votre bibliothèque fonctionne.

Internet est un outil fabuleux pour trouver la bibliothèque qui implémente déjà la fonctionnalité dont vous avez tellement besoin. Des sites comme Koders, Google Code Search, krugle, SourceForge (et son pendant Ruby, RubyForge) ou encore Code Project sont de vraies mines d'informations.

Faites tout de même attention aux licences des ces dites bibliothèques.

5. Travaillez de manière incrémentale

Une des plus grande erreur des programmeurs est de vouloir tout faire d'un seul coup. Au résultat, les bugs s'accumulent et deviennent plus compliqués à trouver et à résoudre.

Il est préférable de travailler étape par étape. Développez une partie de votre application, testez là, débugguez là, utilisez là. De cette manière, votre cerveau se concentrera sur un seul sujet. Vous serez plus efficace et commettrez moins de bugs d'inattention.

Note: Je suis un partisan des méthodes de développement dite Agiles. L'extrem programming nous oblige à justement travailler de manière incrémentale à cause des livraisons rapprochées.

6. Trouvez quelqu'un pour critiquer votre travail

Et même avant de commencer à travailler. Exposez-lui vos idées et la manière dont vous comptez régler le problème. Cela vous permettra d'avoir les idées bien claire et de voir les éventuelles failles de votre logique. Cela permet parfois aussi de voir que l'on est en train de faire quelque chose qui existe déjà (voir point 4).

Une fois votre code écrit, faites le relire par quelqu'un. Un œil extérieur permettra de voir vos hypothétiques erreurs plus facilement.

La critique est le meilleur moyen d'évoluer. Mais ce n'est pas à sens unique. Le lecteur peut aussi apprendre de votre code.

Note: Ici aussi l'extrem programming entre en ligne de compte puisqu'il propose de directement travailler en binôme.

Il est parfois aussi utile de faire des brainstorming avant de se lancer à corps perdu dans un module de votre application.

Conclusion

Ces conseils peuvent paraitre évidents mais sont souvent oubliés dans beaucoup de projets, faute de temps. Il faut parfois perdre un peu de temps pour améliorer les choses pour en gagner plus tard. Faire les choses bien maintenant permet de gagner du temps plus tard, lorsque l'on devra débugguer le code ou y ajouter des fonctionnalités.
Mettre ces conseils en applications ne vous permettra pas seulement de faire du code de meilleur qualité mais aussi de vous rendre plus heureux. Ce n'est jamais marrant de débugguer un code mal conçu où le moindre changement risque d'engendrer d'autres bugs ou effets de bord non prévus.