Conclusion

Le lecteur s’est certainement souvent fait la réflexion, au fur et à mesure de la lecture, que les erreurs de code relevées étaient évidentes, voire même qu’elles n’apparaîtraient pas dans une vraie application. Il est vrai que dans certains cas l’auteur a volontairement forcé le trait. Parfois dans un but pédagogique, parfois pour réduire la taille du code à analyser, et c’est alors ce qui fait ressortir, par exemple, les redondances ou les appels multiples.

Mais toutes les erreurs détaillées ici sont des « classiques ». Bien sûr, elles n’apparaîtront normalement jamais dans du code solide, dédié à des applications critiques ou semi-critiques, pour lesquelles un client est prêt à payer un surcoût important lié aux tests de robustesse et de performance de l’application. Mais l’industrie n’est pas peuplée uniquement de ce genre d’applications, loin s’en faut. Elle fourmille de simples applications, d’utilitaires de gestion de données.

Ce qui ne veut pas dire que ce sont des sous-applications. Par exemple, ce sont souvent des logiciels sur lesquels un gros effort de sécurité est réalisé, et qui sont de fait plus robustes en termes de sécurité que certains logiciels grand public. À l’inverse, la performance n’est souvent pas prise en compte dès...