Un programme est souvent amené à être modifié, adapté, réutilisé par celui qui l'a écrit ou par un autre, sur une longue durée (correction d'erreur, évolution du logiciel, réutilisation dans une autre application...).
Ces conseils visent à réduire les efforts nécessaires lors d'évolutions.
Éviter les constantes littérale (c_mod_1).
Les constantes chaîne, numérique doivent être représentées par des symboles. Les constantes littérales sont interdites.
Justification.
Les constantes littérales dupliquées et réparties dans le code source rendent les modifications plus difficiles : risque d'altération, d'oubli d'une occurrence. Il faut les regrouper sous formes de constantes symboliques (définition du pré-processeurs) en tête de fichier source ou dans des fichiers inclus.
Écrire des commentaires fonctionnels (c_mod_2).
Les commentaires ne doivent pas paraphraser le code, ils doivent expliquer la logique de traitement et justifier les choix effectués (pourquoi tel algorithme, telle structure de données, ...).
Justification.
La personne, qui relira le code source en vue de sa maintenance, aura besoin de comprendre les grandes étapes de l'algorithme, les fonctions réalisées par la suite d'instructions du langage.
Exemple.
Mauvais :
// Incrémentation de i
i = i + 1
Meilleur :
// Passage au fichier suivant
i = i + 1
Pas d'éléments inutiles ou non initialisés (c_mod_3).
Toute fonction définie doit être utilisée et toute variable déclarée doit être initialisée.
Justification.
Évite la présence de code mort qui nuit à la maintenance.
La valeur par défaut d’une variable dépend de facteurs qui peuvent échapper au programmeur. Cette règle évite les fonctionnements aléatoires de certains programmes.
Outils.
Les compilateurs et les outils de vérifications statiques comme splint émettent des avertissements en cas de problème. Certains compilateurs possèdent des options pour générer tous les avertissements sous forme d'erreur, ce qui permet d'interrompre une chaîne de compilation afin de corriger le code.
Pas de duplication de code source (c_mod_4).
Ne pas dupliquer de grandes parties de code dans plusieurs fichiers source.
Justification.
Les parties dupliquées doivent être fusionnées en une seule. Le code commun, éventuellement paramétré, deviendra une fonction. Si des contraintes de performance l'impose, l'inlining pourra être utilisé.
Outils.
La recherche des parties dupliquées pourra se faire avec un outil de recherche de chaînes de caractères : sous UNIX grep ou à l'aide d'un éditeur s'il permet la recherche de texte dans plusieurs fichiers.
Limiter le nombre des variables externes ou globales (c_mod_5).
L'utilisation de variables externes ou globales doit être limité au maximum.
Justification.
Les variables globales peuvent être modifiées par plusieurs unités de compilation, le contrôle des modifications est donc très délicat, les effets de bord sont possibles (modifications non désirées d'une variable ou d'une zone mémoire par du code lié). Un trop grand nombre de variables externes dénote une mauvaise analyse des interfaces entre unités de compilation ou une mauvaise gestion de la portée des variables.
Le mot-clé "static" en C permet, entre autres, de limiter la portées d'une variable globale ou d'une fonction à son seul fichier source. Il garantit que ces fonctions ou variables ne seront pas utilisées, par erreur, par d’autres unités. Les fonctions locales pourraient être masquées ou masquer d’autres fonctions de même nom, mais définies ailleurs dans le projet ou dans une bibliothèque liée. Le comportement du programme pourrait alors dépendre de l’ordre dans lequel les objets et bibliothèques sont présentés à l’édition de lien. Le respect de cette règle allégera l’édition de lien et évitera certains effets de bord.
Ne pas réinventer la roue (c_mod_6).
Utiliser les fonctions et bibliothèques écrites par d'autres programmeurs, principalement dans :
Justification.
Le respect de ce conseil limite le nombre de lignes de code à maintenir ainsi que les efforts nécessaires aux tests du logiciel.
Limiter le nombre de sortie (c_mod_7).
Une fonction ne devrait comporter qu'un seul point de sortie.
Justification.
Diminue la complexité du code et facilite l'analyse du déroulement du programme en mise au point.
Contrôle.
Rechercher des instructions "return" et "exit" à l'aide d'un utilitaire comme grep.
Évitez le type union (c_mod_8).
L’utilisation du type union est déconseillé, sauf pour manipuler des champs de bits.
Justification.
Améliore la portabilité.
Pas de code dans les .h (c_mod_9).
Ne jamais écrire de fonctions ou d'instructions dans les fichiers d’entête .h (excepté les macros instructions).
Justification.
Écrire le corps de fonction dans un fichier .h et l’inclure dans plusieurs sources dupliquerait ce code et pourrait provoquer des erreurs due aux symboles définis plusieurs fois. Plutôt que d’utiliser le pré-processeur, il faut répartir le code source dans différents fichiers .c qui seront compilés séparément et réunit lors de l’édition de lien.
Seuils pour les métriques déterminant la facilité de modification (c_mod_10).
Les métriques suivantes influent sur la facilité de modification d'un programme (ISO/IEC 9126) :
Seuils pour les métriques :

Gnocchi
Conseils de codage en C/Performances
Ces conseils permettent d'obtenir des programmes plus rapides ou utilisant seulement les ressources nécessaires.
Éviter d'éparpiller les entrées-sorties (c_perf_1).
Il faut éviter d'effectuer des entrées sorties dans une partie du programme qui réalise des calculs de façon intensive. Il faut regrouper ces opérations d'échange dans une partie consacrée à l'initialisation ou à l'écriture et la communication des résultats.
Justification.
L’appel répété aux fonctions du système est pénalisant pour les performances. Les accès aux moyens de stockage de masse (disques) ou au réseau sont beaucoup plus longs que les échanges avec les registres ou la mémoire vive.
Utiliser l'algorithme le plus rapide (c_perf_2).
Pour effectuer une même opération, il peut exister différents algorithmes ayant un nombre d'opérations différent. Il faut employer le plus adapté pour obtenir de meilleures performances en temps de réponse.
Justification.
Les instructions issues de la compilation des fichiers sources sont exécutées par un processeur, mais pas de façon simultanée. Certaines opérations prennent plus de temps que d'autres.

Livre de cuisine/Œufs à la Monteynard
Les Œufs à la Monteynard est un plat principal originaire de l'Isère, sorte de gratin de riz accompagné d’œufs.
Le nom de cette recette décrit son origine géographique, le village de Monteynard en Isère.
Ingrédients.
Ingrédients supplémentaires possibles :

Programmation C-C++/Arithmétique des pointeurs