Conseils de codage en C/Programmes plus exploitables
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)[modifier | modifier le wikicode]
Lors d’un nouveau développement, il vaut parfois mieux utiliser une norme récente du langage tel que le C99 .
Justification[modifier | modifier le wikicode]
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)[modifier | modifier le wikicode]
Les chemins d'accès aux fichiers ne doivent pas être écrits en dur dans les fichiers sources.
Justification[modifier | modifier le wikicode]
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)[modifier | modifier le wikicode]
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[modifier | modifier le wikicode]
- 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)[modifier | modifier le wikicode]
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[modifier | modifier le wikicode]
Améliore l’ergonomie du logiciel.
Exemple[modifier | modifier le wikicode]
- 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)[modifier | modifier le wikicode]
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[modifier | modifier le wikicode]
Limite la prolifération des fichiers parasites.
Outils[modifier | modifier le wikicode]
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.