« Conseils de codage en C/Recherche des erreurs » : différence entre les versions

L'application de ces conseils facilite la recherche des erreurs et permet d'en éviter certaines.

 

Utilisez des identificateurs parlants pour les variables. Le nom d’une variable devra rappeler son rôle ou son utilité.

 

*Bon : numMaille

 

La sortie d’une boucle (do, while, for) doit se faire par la condition de test.

 

</source>

 

L’instruction d’une boucle for ne doit contenir aucune instruction vide. De plus, chacun de ses membres doit porter sur au moins une variable commune.

 

L’instruction '''for''' doit permettre le contrôle total d’une itération. Si une instruction est vide, cela veut dire que la boucle aurait pu être écrite sous une autre forme ('''do''' ou '''while''').

 

Les expressions arithmétiques et logiques doivent être placées entre parenthèses.

 

*Bon : if ( ( n & 1 ) == 0 ) ...

 

Les macros doivent être écrites avec des parenthèses autour de leurs paramètres.

 

Meilleur : <code>#define double(a) 2 * (a)</code> : l’appel double(2+1) sera étendu en 2 * (2 +1) : vaudra 6

 

===Justification===

Au-delà de 5 instructions, le déroulement est assimilable à un traitement, et doit faire partie intégrante d’une fonction. De plus, les macros instructions ne permettent pas un contrôle strict de leurs paramètres.

Si l'utilisation d'une fonction entraîne une dégradation des performances, il faut recourir à l’inlining. Le mot clé C99 inline répond à ce problème.

 

Ne pas placer d’opérateurs unaire (++, --) dans les paramètres d’appel des macros.

 

Le résultat est bien souvent imprévisible par suite des effets de bord, surtout en cas de répétition du paramètre dans la définition de la macro.

 

On protégera chaque fichier d’en-tête .h des inclusions multiples.

 

</source>

 

Le calcul d’une expression complexe au sein d’une condition est à éviter.

 

Facilite l’analyse des sources, évite de superposer les erreurs de priorité des opérateurs arithmétiques à ceux des opérateurs relationnels.

 

Les fonctions doivent être prototypées, une fonction ou une variable ne doit pas avoir de type par défaut.

 

Le contrôle du peut être effectué en utilisant le compilateur C avec options les plus strictes ou un outils qualité comme lint ou splint.

 

Une variable ne doit pas en masquer une autre. Cela se produit lorsque deux variables ont le même nom dans des blocs imbriqués.

 

Si la deuxième déclaration de i est supprimée, alors il y a un risque pour que l’incrémentation ne le soit pas, ce serait alors la variable déclarée hors du bloc qui serait utilisée, ce qui ne serait pas le comportement souhaité. Le code resterait alors valide et aucun problème ne serait détectée.

 

===Justification===

Selon le compilateur, il est possible que les données const soient stockées dans une zone accessible en lecture, mais pas l’écriture.

 

Éviter l’utilisation des pointeurs. Préférer l’utilisation des indices de tableau.

 

L’utilisation abusive de pointeurs est la source de graves dysfonctionnements très difficiles à détecter. Les programmeurs habitués à d’autres langages sont souvent perdus face à certaines subtilités du C. Pour les parcours de tableaux, il est préférable d’utiliser des indices (tab[i]) au lieu d’indirection par pointeur.

 

Utiliser le mot - clé ANSI const pour définir :

*Une variable non modifiable.

Rejette, dès la phase de compilation, certaines modifications abusives.

 

Être prudent lors de l'utilisation des identicateurs de tableau et des pointeurs sur chaîne constante.