HOWTO sur la publication de logiciels: Règles d'usage du développement
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.
[22 février 2002, JDNet]
|