Vous vous demandez peut-être ce que l'on entend par le titre. Le code est le code, à droite? Il est important d'être sans bug et c'est tout, quoi d'autre? Le développement est plus que d'écrire du code et de le tester / le déboguer. Imaginez que vous devez lire le travail de quelqu'un d'autre, et je suppose que vous l'avez déjà fait, et toutes les variables sont nommées foo, bar, baz, var, etc. Et le code n'est pas commenté ni documenté. Vous ressentirez probablement l'envie soudaine d'invoquer des dieux inconnus, puis d'aller au pub local et de noyer vos douleurs. Ils disent que vous ne devriez pas faire aux autres ce que vous ne voulez pas vous faire, donc cette partie se concentrera sur les directives de codage générales, ainsi que 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ésoudre tous les exercices et, de préférence, lire et écrire 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 rédiger votre code, et je ne suis pas inventé ces recommandations. Ce sont le résultat d'années de travail par des programmeurs expérimentés, et beaucoup ne s'appliqueront pas seulement à C, mais à d'autres langues, interprétées ou compilées.

Je suppose que la première règle que je veux insister est: commentez votre code, puis vérifiez si vous avez assez commenté, puis commentez un peu plus. Ce n'est pas bénéfique pour d'autres qui liront / utiliseront votre code, mais aussi pour vous. Soyez convaincu que vous ne vous souviendrez pas exactement ce que vous vouliez écrire après deux ou trois mois, et vous ne savez pas quoi int ghrqa34; était censé signifier, si quelque chose. Les bons développeurs commentent (presque) chaque ligne de leur code aussi complètement que possible, et le gain est plus que ce que vous ne le pensez peut-être au début, malgré le temps accru qu'il faut pour rédiger le programme. Un autre avantage est qu'en commentant, car c'est ainsi que notre cerveau fonctionne, tout ce que nous voulions faire sera mieux rappelé, alors encore une fois, vous ne regardez pas votre code, avant quelques mois, vous vous demandant qui a écrit votre code. Ou pourquoi.

L'analyseur C ne se soucie pas vraiment de la façon dont votre code est commandé. Cela signifie que vous pouvez écrire un programme typique de «Hello, World» comme celui-ci, et il se compiliait toujours:

#include int main () printf ("Bonjour, monde!"); retour 0; 

Cela semble beaucoup plus lisible comme nous l'avons écrit la première fois, n'est-ce pas? Les règles générales concernant le formatage sont: une instruction par ligne, choisissez votre largeur d'onglet et soyez cohérent avec elle, mais assurez-vous qu'elle est conforme aux directives du projet, si vous travaillez sur une délimiter diverses parties du programme, ainsi que des commentaires, et enfin, bien que cela ne soit pas nécessairement lié au style codant, avant de commencer à coder sérieusement, trouvez un éditeur que vous aimez et apprenez à bien l'utiliser. Nous publierons bientôt un article sur les éditeurs, mais d'ici là, Google vous aidera avec quelques alternatives. Si vous entendez des gens sur des forums, des listes de diffusion, etc. Dire «Éditeur X Sucks, éditeur Y FTW!", ignore les. C'est une question très subjective et ce qui est bon pour moi pourrait ne pas être si bon 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.

Être cohérent dans la dénomination variable. Assurez-vous également que les noms correspondent aux autres, il y a donc l'harmonie dans l'ensemble du programme. Cela s'applique même si vous êtes le seul auteur du logiciel, il sera plus facile à maintenir plus tard. Créez une liste de préfixes et de suffixes utilisés (E.g. Max, min, get, set, est, cnt) et allez avec eux, sauf indication contraire. La cohérence est le mot clé ici.

Lignes directrices 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 souhaite 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 entretenez un logiciel GNU, mais vous trouverez les parties les plus importantes ci-dessous. Un premier problème à mentionner est de savoir comment gérer les prototypes de fonction. Revenez à la partie en traitant cela si vous avez des problèmes. L'idée est «Si vous avez vos propres fonctions, utilisez une déclaration prototype avant main (), puis définissez la fonction en cas de besoin."Voici un exemple:

#include int func (int, int) int main () […] int func (int x, int z) […] 

Utilisez une indentation appropriée et constante. Cela ne peut pas être suffisamment souligné. Les programmeurs expérimentés avec des années et des années de code derrière le prendront très mal lorsque vous soumettez du code avec une indentation incorrecte. Dans notre cas, la meilleure façon de s'habituer à la façon dont GNU fait cela en utilisant GNU Emacs (bien que ce ne soit pas sous forme de notre manière de vous dire que «GNU Emacs est bon pour vous, utilisez-le.», Comme nous sommes les partisans du libre arbitre et du choix), où le comportement par défaut du code C est l'indentation définie dans deux espaces et accolades sur une ligne pour eux-mêmes. Ce qui nous amène à un autre problème important. Certaines personnes utilisent des accolades comme ceci:

alors que (var == 1) code… 

… Alors que d'autres, y compris les gens GNU, font-le comme ceci:

alors que (var == 1) code…

Bien sûr, cela s'applique également aux expressions conditionnelles, aux fonctions et à chaque occasion où vous devez utiliser des accolades dans le code C. Pour autant que ce soit remarqué, ce choix est quelque chose de très spécifique au GNU, et combien vous respectez dépend uniquement de votre goût et de votre position sur la question.

Notre prochain numéro est technique, et une promesse que je devais tenir: le problème malloc (). En plus d'écrire des messages d'erreur pertinents et significatifs, contrairement à ceux que nous avons tous vus dans d'autres systèmes d'exploitation, vérifiez que Malloc () et les amis renvoient toujours zéro. Ce sont des problèmes très graves, et vous obtiendrez quelques leçons de mots sur Malloc () et quand l'utiliser. Vous savez maintenant ce que l'allocation de la mémoire automatique ou statique. Mais ces méthodes ne couvrent pas toutes les bases. Lorsque vous devez allouer la mémoire et avoir plus de contrôle sur l'opération, il y a malloc () et des amis, pour une allocation dynamique. Son objectif est d'allouer la mémoire disponible à partir du tas, Ensuite, le programme utilise la mémoire via un pointeur que Malloc () renvoie, puis ladite mémoire doit être libre () D. Et «must» doit être écrit avec des capitales en lettres de 2 pieds avec une couleur rouge brûlante. 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.

Vous êtes invité à utiliser une interface cohérente dans tous vos programmes de ligne de commande. Si vous êtes déjà un utilisateur GNU / Linux chevronné, vous avez remarqué que presque tous les programmes ont une vision et un help, plus, par exemple, -v pour Verbose, si tel est le cas. Nous ne pénétrerons pas dans tout cela ici; Prenez une copie des normes de codage GNU, vous en aurez quand même besoin.

Bien que j'ai personnellement tendance à ignorer 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 notre cerveau fonctionne. L'idée est: lorsque vous doutez d'utiliser 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. Il y en a d'autres qui disent «pourquoi éviter les IF nichés?"Et il y en a d'autres encore qui n'utilisent tout simplement pas IFS nichés. Vous allez créer votre propre opinion à ce sujet au fil du temps et des lignes de code que vous écrivez augmenter. L'idée est, si vous les utilisez, les rendre aussi lisibles que 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 que votre code soit aussi portable que possible, «mais pas paramount». Matériel portable en termes de? Cela dépend de l'objectif du programme et des machines que vous avez à votre disposition. Nous nous référons davantage au côté logiciel, à savoir la portabilité entre les systèmes UNIX, l'open source ou non. Évitez les IFDEFS si vous le pouvez, évitez les hypothèses concernant les emplacements des fichiers (e.g. Solaris installe des logiciels tiers sous / opt, tandis que BSD et GNU / Linux ne le font pas), et visent généralement le code propre. En parlant d'hypothèses, ne présumez même pas qu'un octet est de huit bits ou que l'espace d'adressage d'un processeur doit être un numéro pair.

Documenter votre code, sous forme de pages manuelles et de lectures bien écrites et ainsi de suite, 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, il est de votre responsabilité de le faire, car chaque bon programmeur fait son travail de A à Z.

Conclusion

La prochaine fois, nous continuerons à partir de l'endroit où nous nous sommes arrêtés ici: passer de l'idée à un programme complet, avec des makefiles, une documentation, des cycles de sortie et tous les trucs amusants. Le seul exercice que j'ai pour vous est de parcourir les normes de codage GNU et de modifier votre code pour se conformer. Et préparez-vous, la prochaine fois, c'est le moment amusant!

Voici ce à quoi vous pouvez vous attendre ensuite:

• je. C Développement sur Linux - Introduction
• Ii. Comparaison entre C et d'autres langages de programmation
• III. Types, opérateurs, variables
• Iv. Contrôle de flux
• V. Les fonctions
• Vi. Pointeurs et tableaux
• Vii. Structure
• Viii. E / S de base
• Ix. Style de codage et recommandations
• X. Construire un programme
• Xi. Emballage pour Debian et Fedora
• Xii. Obtenir un forfait dans les référentiels officiels Debian

Tutoriels Linux connexes:

• Tutoriel de débogage GDB pour les débutants
• Installez Arch Linux dans VMware Workstation
• Une introduction à l'automatisation Linux, des outils et des techniques
• Choses à installer sur Ubuntu 20.04
• Python Expressions régulières avec des exemples
• Comment créer une application Tkinter à l'aide d'un objet orienté…
• Advanced Bash Regex avec des exemples
• Boucles de bash avec des exemples
• Choses à faire après l'installation d'Ubuntu 20.04 Focal Fossa Linux
• Boucles imbriquées dans les scripts bash