Blog de Gilles Vasseur - Pascal et compagnie

Lorsque je compile une nouvelle bibliothèque afin de l'incorporer à Lazarus ou que je teste une application, je dois avouer que je suis très sensible aux messages du compilateur. En premier lieu, rien ne m'exaspère plus qu'un travail proposé à la communauté qui ne compile pas . L'erreur fatale est rédhibitoire et ne me donne pas envie d'aller plus loin : après tout, si je souhaite utiliser un produit tiers, c'est qu'il m'intéresse pour les fonctionnalités qu'il procure, mais aussi parce que je vais lui faire confiance, sans aucun préjugé sur sa fiabilité. Un plantage à la compilation me refroidit par conséquent sur le champ.

Mais je suis aussi attentif aux avertissements et aux remarques, deux types de messages qui, sous prétexte qu'ils ne bloquent pas la compilation, sont à mon avis trop souvent négligés.

Quant une bibliothèque égrène des centaines d'avertissements, ma confiance diminue au fur et à mesure du défilé de leur notification. Comment distinguer ce qui est sans importance et ce qui va se payer à plus ou moins long terme ? En particulier, je suis sensible aux avertissements en lien avec la gestion de la mémoire et à l'emploi de fonctions ou procédures obsolètes. Pour ces dernières, il existe toujours un équivalent plus récent et j'invite fortement tout le monde à l'utiliser : ainsi, il convient de ne plus faire référence, sauf cas très particuliers comme une compatibilité avec d'anciennes applications, à des routines n'utilisant pas l'UTF8. Pour ce qui est de la gestion de la mémoire, en particulier les transtypages hasardeux, j'invite à toujours évaluer le danger encouru : la plupart du temps, c'est un préjugé sur l'implémentation d'une fonctionnalité particulière qui est en cause alors qu'il ne faut jamais fonder son travail sur ce qui est susceptible d'être modifié un jour. Ceux qui ont fondé des applications sur la manipulation sauvage des chaînes courtes de caractères ont compris leur erreur lorsque les chaînes longues sont apparues, tout comme ceux qui ont bâti des analyses de chaînes sur les caractères ASCII ont été plus que perturbés lors du passage à l'Unicode. Certaines fois, il s'agit d'erreurs de débutant qui n'invitent encore une fois pas à la tranquillité d'esprit : une variable locale non initialisée est source d'erreurs potentielles graves, aussi faut-il écouter le compilateur lorsqu'il se plaint !

Restent les simples remarques (hints). A priori, elles sont moins gênantes, mais elles devraient elles aussi être éliminées. Pourquoi laisser traîner une unité dans une clause uses alors qu'elle est inutile ? Le risque n'est pas si anodin qu'on pourrait le croire à première vue : même si elle est totalement inutile, il suffit qu'un autre programmeur n'ait pas cette unité pour que l'application ne se compile plus ! D'autres cas sont bien plus bénins, mais méritent cependant qu'on s'y intéresse : est-ce volontairement qu'un argument n'a pas été utilisé ? Pourquoi une variable locale est-elle présente et sans emploi ? Ce ne sont que de petites négligences, mais qui freinent la compréhension du code par une personne extérieure. L'élimination des variables locales non utilisées, l'insertion de commentaires judicieusement choisis, l'utilisation de la directive {%H-} devant un paramètre volontairement non utilisé (par exemple dans un gestionnaire d'événement), voilà autant de possibilités qui ne coûtent pas cher en temps et qui en font beaucoup gagner à la relecture.

Bien sûr, je viens de décrire des aspects d'un code parfait qui n'existe pas, mais j'invite chacun à ne pas publier à la va-vite et à rechercher un certain confort pour celui à qui s'adresse la production en cours : publier le code source est une excellente chose à condition que ce code source soit vraiment exploitable.