Page suivantePage pr�c�denteTable 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 suivantePage pr�c�denteTable des mati�res

Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:16