Développement C sous Linux - Style de codage et recommandations - IX.

Introduction

Vous vous demandez peut-être ce que signifie le titre. Le code est le code, n’est-ce pas ? Il est important de ne pas avoir de bugs et c’est tout, quoi d’autre ? Le développement ne se limite pas à l’écriture de code et à ses tests/débogages. Imaginez que vous deviez lire le travail de quelqu’un d’autre, et je suppose que vous l’avez déjà fait, et que toutes les variables sont nommées foo, bar, baz, var, etc. Et le code n’est ni commenté ni documenté. Vous ressentirez probablement l’envie soudaine d’invoquer des dieux inconnus, puis d’aller au pub local et de noyer vos chagrins. Ils disent que vous ne devriez pas faire aux autres ce que vous ne voulez pas qu’on vous fasse, donc cette partie se concentrera sur les directives générales de codage, ainsi que sur des idées spécifiques à GNU qui vous aideront à faire accepter votre code. Vous êtes censé avoir lu et compris les parties précédentes de cette série, ainsi que résolu tous les exercices et, de préférence, lu et écrit autant de code que possible.

Recommandations

Avant de commencer, veuillez prendre note de la signification réelle du mot ci-dessus. Je ne veux en aucun cas vous dire comment écrire votre code, ni inventer ces recommandations. Ceux-ci sont le résultat d’années de travail par des programmeurs expérimentés, et beaucoup ne s’appliqueront pas seulement au C, mais à d’autres langages, interprétés ou compilés.

Je suppose que la première règle sur laquelle je veux insister est la suivante : commentez votre code, puis vérifiez si vous avez suffisamment commenté, puis commentez encore. Ce n’est pas bénéfique pour les autres qui liront/utiliseront votre code, mais aussi pour vous. Soyez convaincu que vous ne vous souviendrez pas exactement de ce que vous vouliez écrire après deux ou trois mois, ni ne saurez ce que int ghrqa34 ; était censé signifier, le cas échéant. Les bons développeurs commentent (presque) chaque ligne de leur code de manière aussi approfondie que possible, et le gain est plus important que ce que vous pourriez réaliser au début, malgré le temps supplémentaire nécessaire à l’écriture du programme. Un autre avantage est qu’en commentant, parce que c’est ainsi que fonctionne notre cerveau, tout ce que nous avons voulu faire sera mieux mémorisé, donc encore une fois vous ne regarderez pas votre code, avancez de quelques mois, en vous demandant qui a écrit votre code. Ou pourquoi.

L’analyseur C ne se soucie pas vraiment de l’ordre de votre code. Cela signifie que vous pouvez écrire un programme typique « Hello, world » comme celui-ci, et il compilerait toujours :

#include <stdio.h> int main(){printf("Hello, world!"); return 0;}

Il semble beaucoup plus lisible de la façon dont nous l’avons écrit la première fois, n’est-ce pas ? Les règles générales concernant le formatage sont les suivantes : une instruction par ligne, choisissez la largeur de votre onglet et soyez cohérent avec celle-ci, mais assurez-vous qu’elle est conforme aux directives du projet, si vous travaillez sur l’un d’entre eux, faites également un usage libéral des lignes vides, pour délimiter les différentes parties du programme, avec des commentaires, et enfin, Bien que cela ne soit pas nécessairement lié au style de codage, avant de commencer à coder sérieusement, trouvez un éditeur que vous aimez et apprenez à bien l’utiliser. Nous publierons prochainement un article sur les rédacteurs, mais d’ici là, Google vous aidera avec quelques alternatives. Si vous entendez des gens sur les forums, les listes de diffusion, etc. dire « l’éditeur x est nul, l’éditeur y FTW ! », ignorez-les. C’est une question très subjective et ce qui est bon pour moi ne l’est peut-être pas tant que ça pour vous, alors essayez au moins certains des éditeurs disponibles pour Linux pendant quelques jours chacun avant même de commencer à essayer de créer une opinion.

Soyez cohérent dans la dénomination des variables. Assurez-vous également que les noms correspondent aux autres, afin qu’il y ait une harmonie dans l’ensemble du programme. Cela s’applique même si vous êtes le seul auteur du logiciel, il sera plus facile à maintenir par la suite. Créez une liste de préfixes et de suffixes utilisés (e.g. max, min, get, set, is, cnt) et utilisez-les, sauf indication contraire. La cohérence est le mot clé ici.

Directives spécifiques à GNU

Ce qui suit est un résumé des normes de codage GNU, car nous savons que vous n’aimez pas lire de telles choses. Donc, si vous écrivez du code qui aimerait s’intégrer dans l’écosystème GNU, c’est le document à lire. Même si vous ne le faites pas, c’est toujours une bonne lecture sur la façon d’écrire du code approprié.

Ce document vaut toujours la peine d’être lu dans son intégralité si vous créez ou maintenez un logiciel GNU, mais vous trouverez les parties les plus importantes ci-dessous. Une première question qui mérite d’être mentionnée est la façon de traiter les prototypes de fonctions. Veuillez revenir à la partie qui traite de cela si vous avez des problèmes. L’idée est la suivante : « Si vous avez vos propres fonctions, utilisez une déclaration de prototype avant main(), puis définissez la fonction si nécessaire. » Voici un exemple :

#include <stdio.h>

int func (int, int)

int main() 

[...]

int func (int x, int z)

[...]

Utilisez une indentation appropriée et constante. On ne le soulignera jamais assez. Les programmeurs expérimentés avec des années et des années de code derrière vous le prendront très mal lorsque vous soumettrez du code avec une indentation incorrecte. Dans notre cas, la meilleure façon de s’habituer à la façon dont GNU fait cela est d’utiliser GNU Emacs (bien que ce ne soit en aucun cas notre façon de vous dire que « GNU Emacs est bon pour vous, utilisez-le. », car nous sommes partisans du libre arbitre et du choix), où le comportement par défaut du code C est l’indentation fixée à deux espaces et les accolades sur une ligne pour eux-mêmes. Ce qui nous amène à une autre question importante. Certaines personnes utilisent des appareils orthodontiques comme ceci :

while (var == 1) {
  code...
}

... tandis que d’autres, y compris des gens GNU, le font comme ceci :

while (var == 1)
{
  code...
}

Bien sûr, cela s’applique également aux expressions conditionnelles, aux fonctions et à toutes les occasions où vous devez utiliser des accolades dans le code C. Pour autant que je m’en aperçoive, ce choix est quelque chose de très spécifique à GNU, et le respect que vous respectez cela dépend uniquement de vos goûts et de votre position sur la question.

Son but est d’allouer la mémoire disponible à partir du tas, puis le programme utilise la mémoire via un pointeur que malloc() renvoie, puis ladite mémoire doit être libérée. Et « doit » doit être écrit avec des majuscules en lettres de 2 pieds avec une couleur rouge brûlant. C’est à peu près tout avec malloc(), et les raisons ont déjà été exposées plus tôt dans la partie précédente.

Nous vous recommandons d’utiliser une interface cohérente dans tous vos programmes en ligne de commande. Si vous êtes déjà un utilisateur chevronné de GNU/Linux, vous avez remarqué que presque tous les programmes ont -version et -help, plus, par exemple, -v pour verbose, si tel est le cas. Nous n’entrerons pas dans tout cela ici ; prenez une copie des normes de codage GNU, vous en aurez besoin de toute façon.

Bien que j’aie personnellement tendance à négliger cela, et pour beaucoup, c’est un problème mineur, cela améliorera la lisibilité de votre code, car, encore une fois, c’est ainsi que fonctionne notre cerveau. L’idée est la suivante : lorsque vous avez des doutes sur l’utilisation des espaces, utilisez-les. Par exemple:

int func (var1, var2);

int func(var1,var2);

Il y en a qui disent que vous ne pouvez pas éviter les si imbriqués. Il y en a d’autres qui disent « pourquoi éviter les si imbriqués ? » Et il y en a encore d’autres qui n’utilisent tout simplement pas de si imbriqués. Vous vous ferez votre propre opinion à ce sujet au fur et à mesure que le temps passe et que les lignes de code que vous écrivez augmentent. L’idée est, si vous les utilisez, de les rendre aussi lisibles qu’il est humainement possible, car ils peuvent facilement conduire à un code presque spaghetti, difficile à lire et à maintenir. Et encore une fois, utilisez des commentaires.

La norme de codage GNU dit qu’il est bon d’avoir votre code aussi portable que possible, « mais pas primordial ». En ce qui concerne le matériel portable ? Cela dépend de l’objectif du programme et des machines dont vous disposez. On fait plutôt référence au côté logiciel, à savoir la portabilité entre systèmes Unix, open source ou non. Évitez les ifdefs si vous le pouvez, évitez les suppositions concernant l’emplacement des fichiers (par exemple, Solaris installe des logiciels tiers sous /opt, alors que BSD et GNU/Linux ne le font pas), et visez généralement un code propre. En parlant d’hypothèses, ne supposez même pas qu’un octet est composé de huit bits ou que l’espace d’adressage d’un processeur doit être un nombre pair.

Documenter votre code, sous la forme de pages de manuel et de README bien écrits, etc., est un autre aspect primordial du développement de logiciels. Oui, c’est une tâche fastidieuse, mais si vous n’avez pas de rédacteur de documentation dans votre équipe, c’est votre responsabilité de le faire, car tout bon programmeur fait son travail de A à Z.

Conclusion

La prochaine fois, nous reprendrons là où nous nous sommes arrêtés ici : passer de l’idée à un programme complet, avec des Makefiles, de la documentation, des cycles de publication et toutes les choses amusantes. Le seul exercice que j’ai pour vous est de parcourir les normes de codage GNU et de modifier votre code pour qu’il soit conforme. Et préparez-vous, la prochaine fois c’est le moment du plaisir !

Voici ce à quoi vous pouvez vous attendre ensuite :

• Développement I. C sur Linux – Introduction
• II. Comparaison entre le C et d’autres langages de programmation
• III. Types, opérateurs, variables
• IV. Contrôle des flux
• V. Fonctions
• VI. Pointeurs et tableaux
• VII. Structures
• VIII. E/S de base
• IX. Style de codage et recommandations
• X. Construire un programme
• XI. Empaquetage pour Debian et Fedora
• XII. Obtenir un paquet dans les dépôts officiels de Debian