# Conseils de codage en C/Programmes plus exploitables

Maintenabilité
* Pour la lisibilité
* Pour la détection des erreurs
* Pour des modifications plus faciles
Fiabilité
* Pour la robustesse
* Pour les performances
* Pour la sécurité
Qualité
* Pour une utilisation plus facile
* Pour la qualité numérique
Maintenabilité
* Pour la lisibilité
* Pour la détection des erreurs
* Pour des modifications plus faciles
Fiabilité
* Pour la robustesse
* Pour les performances
* Pour la sécurité
Qualité
* Pour une utilisation plus facile
* Pour la qualité numérique
Livre
[ Modifier le sommaire ]
Ces quelques conseils permettent de réaliser des programmes plus faciles à utiliser, plus faciles à porter sur une autre architecture.

## Utiliser la norme la plus récente (c_exp_1)

Lors d’un nouveau développement, il vaut parfois mieux utiliser une norme récente du langage tel que le C99 .

### Justification

Le codage est plus efficace lors de l’utilisation des nouvelles fonctionnalités introduite par la norme (mot-clé restrict, type de taille fixe, tableau de taille variable (VLA), boolean...).
Le programme sera plus facile à reconstruire et à porter sur une autre machine dans le futur.

## Tout chemin d’accès figé est interdit (c_exp_2)

Les chemins d'accès aux fichiers ne doivent pas être écrits en dur dans les fichiers sources.

### Justification

Un programme doit être paramétrable sans avoir à modifier ses fichiers sources et le recompiler.
Les chemins d'accès aux ressources doivent être récupérés depuis l’environnement ou depuis des fichiers de configuration : de préférence dans un format auto-décrit et éditable : comme XML.

## Code retour du programme (c_exp_3)

Un programme doit toujours renvoyer la valeur 0 (EXIT_SUCCESS de stdlib.h) en cas de fin correcte ou un code erreur en cas d’incident (généralement EXIT_FAILURE de stdlib.h).

### Justification

* Ce comportement respecte le standard de fonctionnement d'UNIX et peut s'appliquer à d'autres système (MS-DOS/Windows).
* Permet d’utiliser un programme dans une chaîne de traitement par lot et d'arrêter le déroulement en cas d'erreur.

## Des messages d'erreur utiles (c_exp_4)

Les messages d'erreur émis par les logiciels doivent aider les utilisateurs :
* L'utilisateur doit pouvoir les comprendre : par leur langue, par leur vocabulaire.
* Ils doivent lui permettre de corriger le problème ou de contacter un support technique.
* Ils doivent proposer éventuellement un moyen de contournement, une cause probable.
* Leur contenu doit différer selon qu'ils sont destinés à l'utilisateur ou à la personne qui assure la maintenance.
* Ils doivent permettre par un moyen (fichier de log par exemple) de fournir à la maintenance le plus possible d’informations : version du programme, date, nom de l’utilisateur, plate forme, nom de fonction, numéro de ligne, message système, valeurs ayant provoqué l’erreur…

### Justification

Améliore l’ergonomie du logiciel.

### Exemple

* Mauvais message : Can’t open file, puis arrêt brutal du programme.
* Meilleur message : Accès impossible en écriture au fichier configuration.txt. Vérifiez ses droits d’accès.

## Fichiers temporaires (c_exp_5)

Les fichiers temporaires doivent être générés dans les répertoires prévus à cet effet. Ils doivent être détruits à la fin de l’exécution (qu’il s’agisse d’une terminaison normale ou dégradée).

### Justification

Limite la prolifération des fichiers parasites.

### Outils

Une analyse des appels systèmes en cours d'exécution du logiciel peut se réaliser avec un utilitaire comme strace pour UNIX ou ktrace sur Mac. Analyse des modifications du système de fichiers.