Page suivante - Page précédente - Table des matières

5. Règles d'usage du développement

La plupart de ces règles visent à assurer la portabilité, non seulement entre les différentes distributions de Linux, mais aussi avec d'autres variétés d'Unix. La portabilité vers Unix n'est pas seulement une question de professionnalisme ou de savoir-vivre entre programmeurs, c'est aussi une assurance non négligeable contre les évolutions futures de Linux lui-même.

D'autres personnes finiront par essayer de compiler votre code dans d'autres environnements que Linux ; avec la portabilité, vous recevrez moins de messages ennuyeux de la part d'utilisateurs perplexes.

5.1 Ecrivez soit en C ANSI pur, soit dans un langage de script portable

Pour des raisons de portabilité et de stabilité, il est fortement recommandé d'écrire soit en C ANSI pur, soit dans un langage de script dont la portabilité soit garantie par une implémentation multi-plateforme unique.

Parmi les langages de script, Python, Perl, Tcl, Emacs Lisp et PHP respectent ce critère. Le bon vieux shell ne convient pas ; il existe trop d'implémentations différentes, chacune ayant des particularités subtiles, et l'environnement du shell est souvent transformé de manière imprévisible par des configurations propres à chaque utilisateur, comme les alias.

Java promet beaucoup sur le plan de la portabilité, mais les implémentations disponibles sur Linux sont encore sommaires et mal intégrées dans le système d'exploitation. Java est encore un choix exotique, bien qu'il ait de fortes chances de gagner en popularité lorsqu'il aura plus de maturité.

5.2 Respectez les règles de portabilité du C

Si vous écrivez en C, n'hésitez pas à utiliser à fond les fonctionnalités décrites dans la norme ANSI -- y compris les prototypes de fonction, qui vous aideront à repérer les incohérences entre modules. Les compilateurs du type K&R relèvent du passé.

En revanche, ne supposez pas que certaines caractéristiques spécifiques à GCC comme l'option `-pipe' ou les fonctions imbriquées sont disponibles. Cela vous poursuivra et vous vous en repentirez le jour où quelqu'un portera votre logiciel vers un système autre que Linux, ou dépourvu de GCC.

5.3 Utilisez autoconf/automaker/autoheader

Si vous écrivez en C, utilisez autoconf/automaker/autoheader pour assurer la portabilité, vérifier la configuration du système et affiner vos makefiles. De nos jours, les gens qui compilent à partir des sources s'attendent à devoir juste taper "configure; make" et que tout se compile proprement - sans la moindre erreur.

5.4 Soignez la rigueur de votre code avant chaque nouvelle version

Si vous écrivez en C, faites une compilation de test avec l'option -Wall et corrigez les erreurs résultantes, au moins une fois avant chaque nouvelle version. On trouve comme cela un nombre surprenant d'erreurs. Pour être vraiment complet, compilez aussi avec l'option -pedantic.

Si vous écrivez en Perl, vérifiez votre code avec perl -c (voire -T dans les cas adéquats). Utilisez perl -w et 'use strict' religieusement (consultez la documentation de Perl pour plus d'informations).

5.5 Soignez votre documentation et vos README avant la livraison

Passez-les au correcteur d'orthographe. Si vous donnez l'impression de ne pas connaître l'orthographe et de vous en moquer, les gents penseront que vous avez aussi bâclé votre code.

Page suivante - Page précédente - Table des matières