if(0==x) et non if(x==0) ?{' et '}' autour des boucles ?goto ?#endif ?Tout morceau de code qui n'est pas standard doit être abondamment commenté afin de rendre le portage vers d'autres cibles le moins fastidieux possible, l'idéal étant d'utiliser des macros.
Il est également important de bien structurer son programme en modules, puis en fonctions. Certains vont jusqu'à dire qu'une fonction ne doit pas dépasser la taille d'un écran.
Les déclarations et prototypes doivent être regroupés dans des fichiers d'en-têtes, avec les macros.
Enfin, il est très important de bien présenter le code, avec une indentation judicieuse et des sauts de ligne. (cf. 15.2) Il est généralement admis que les lignes ne doivent pas dépasser 80 caractères.
Pour le reste, c'est une histoire de goût.
Pour éviter tout problème, et améliorer la lisibilité du code,
il faut utiliser uniquement des espaces.
Un éditeur correct doit pouvoir générer un nombre d'espaces fixe
(voire une indentation automatique) lorsqu'on appuye sur la touche
<TAB> (ou autre raccourci).
Personnellement, je règle à 4 espaces par tabulation.
Il existe des styles de programmations fréquemment utilisés en C, comme les styles K&R ou GNU. Le style K&R est le style « historique », et c'est pourquoi il est très utilisé. Le style GNU est utilisé pour tous les projets de la Free Software Fundation.
Sur le site FTP caramba.cs.tu-berlin.de , le repertoire /pub/doc/style contient quelques documents intéressants sur la question.
szname, sz signifiant « string
zero », ou chaîne terminée par un '\0'.
Personnellement, je ne trouve pas cette convention toujours pratique. Le nom de la variable doit avant tout refléter son rôle.
if(0==x) et non if(x==0) ?= au lieu de
==. Comme 0 n'est pas une lvalue
(cf. 10.10), cette étourderie
provoquera une erreur, simple à détecter.
Dans le même genre, on peut écrire while (0 == x).
Certains compilateurs préviennent lorsque l'on fait une affectation là ou est attendu un test. C'est le cas de GNU CC, avec l'option -Wall.
Lorsque l'on écrit while ( c = fct() ), certains
compilateurs râlent en croyant que l'on s'est trompé entre le
= et le ==. Pour éviter cela, il suffit de
rajouter un paire de parenthèses.
while ( (c= fct()) ) {
/* ... */
}
{' et '}' autour des boucles ?
for(i = 0; i < N; i++);
tab[i] = i;
De plus, cela permet une plus grande simplicité dans l'évolution du code. En effet, les programmes ont tendance à s'épaissir avec le temps.
goto ?goto est une instruction qui permet de casser l'aspect
structuré d'un programme. Des goto mal utilisés
permettent de rendre un code totalement illisible (code
spaghetti), d'autant plus qu'avec les structures de
boucles traditionnelles, on peut souvent s'en passer.
Toutefois, il arrive parfois que l'utilisation d'un goto
rende le code plus propre. C'est le cas, par exemple, des sorties
de boucles imbriquées en cas d'erreur.
Cela rejoint le cas plus général des gestions d'exceptions
internes.
Poser comme règle de ne jamais utiliser les
goto est une absurdité.
Par contre, avertir le programmeur de l'utiliser avec parcimonie,
et avec beaucoup de précautions me semble une bonne chose.
#endif ?#endif ne peut être suivi par autre chose qu'un
commentaire. On commente donc
pour savoir à quelle directive il correspond :
#if FOO
/* du code ou des directives */
#ifdef BAR
/* encore du code ou des directives */
#endif /* BAR */
/* encore du code ou des directives */
#endif /* FOO */
Sachez également qu'il existe un programme indent
issu de BSD qui réindente automatiquement du code,
suivant un style donné. Les options classiques de la version
GNU de cet utilitaire sont -kr (pour le
style décrit dans K&R), -gnu (pour le
style utilisé dans les projets GNU) ou encore
-orig (pour le style BSD).
(Informations bienvenues à guillaume.rumeau@wanadoo.fr )
La phase suivant du développement est l'intégration. Elle consiste à mettre la colle qui va bien pour faire tenir tout les modules ensembles et à tester le fonctionnement de l'ensemble.
Rappel des 5 phases (en 'V') de développement d'un projet :
1 - Spécification 5 - Validation
\ /
2 - Conception 4 - Integration
\ /
3 - Codage et test unitaire
Voir à ce sujet les questions 9.3 et 13.5. Merci à Emmanuel Delahaye pour cet réponse.
faq-fclc 5/3/2002 (8h 59:05)