5 conseils pour améliorer la lisibilité et la robustesse du code C

Chaque année, je lis et révise pas mal de code C. Dans l’ensemble, je sens que la qualité du code que je vois aujourd’hui par rapport à il y a cinq ans s’améliore, mais cela pourrait être simplement le code auquel je suis exposé, mon influence sur les équipes avec lesquelles je travaille ou simplement un vœu pieux. Malgré les améliorations que je vois, il y a plusieurs problèmes que je rencontre souvent et qui pourraient être résolus pour améliorer la lisibilité et la robustesse du code. Vous trouverez ci-dessous quelques conseils à prendre en compte lors de la rédaction de vos applications C.

Astuce n ° 1 – Longueur de l’instruction du commutateur de limite

Les instructions Switch sont utilisées pour contrôler le flux de code en fonction d’une valeur ou de l’évaluation d’une expression. Ils sont souvent utilisés pour remplacer une longue instruction if / else if / else ou pour déterminer quel code doit s’exécuter dans une machine à états. Ils sont également souvent utilisés dans l’exécution de commandes dans un système. Il n’est pas rare que je rencontre des instructions switch auxquelles sont associées des milliers de lignes de code. Ces instructions de commutation volumineuses sont souvent difficiles à lire et à comprendre l’exécution du code, en particulier lorsque les instructions case contiennent des évaluations, une logique de branchement supplémentaire et des appels de fonction.

Je recommande souvent que les instructions switch soient limitées à 5 à 7 cas maximum et que chaque cas inclue une fonction ou une fonction en ligne associée au cas pour simplifier l’instruction switch. Lorsque les instructions de commutation dépassent la règle empirique des sept cas, ce qui se produit souvent dans le traitement des commandes, les développeurs peuvent à la place utiliser un tableau de pointeurs de fonction et indexer le tableau pour déterminer quelle fonction exécuter. Cela améliore la lisibilité et la flexibilité du code tout en diminuant sa complexité.

Astuce #2 – Placez des accolades sur leurs propres lignes

Le placement des crochets bouclés est un peu ma bête noire. Je trouve extrêmement difficile de lire rapidement le code et de repérer les erreurs lorsque le code ressemble à ce qui suit :

if(variable >= valeur){

variable = valeur ;

}

Lors d’une lecture rapide, il est utile d’aligner le code et les crochets pour que le code soit facile à lire. Aujourd’hui, bon nombre de programmeurs semblent aimer placer le crochet sur la même ligne, ce dont je ne sais pas si c’est pour se vanter d’avoir écrit une fonction en moins de lignes ou quoi. Du point de vue de la révision du code et pour s’assurer que les crochets ne sont pas placés au mauvais endroit, les placer sur des lignes séparées améliore considérablement la lisibilité, comme vous pouvez le voir ci-dessous :

if(variable >= valeur)

{

variable = valeur ;

}

C’est plus clair, en espaçant le code, et dans le pire des cas, vous pouvez vous vanter d’avoir écrit une ligne de code supplémentaire, ce qui donne l’impression que plus de travail a été fait plutôt que d’être plus intelligent.

Astuce n°3 – Vérifiez les valeurs de retour des fonctions

Lorsque j’ai appris à programmer pour la première fois, j’ai eu l’idée de vérifier et de valider les entrées et les sorties. Je vois beaucoup de code qui fera un appel à une fonction qui renverra un succès ou un échec ou fournira des informations utiles, mais le développeur l’ignore complètement. En tant que développeurs, nous devons vérifier chaque valeur de retour et ne pas simplement supposer que tout s’est bien passé. Je vois souvent des développeurs sauter la valeur de retour et penser qu’ils vont simplement le faire et plus tard, ils reviendront en arrière et ajouteront les vérifications lorsqu’ils auront plus de temps. Lorsqu’il s’agit de développement de produits, il n’y a jamais « plus de temps », il est donc préférable de faire le travail correctement du premier coup.

Certains compilateurs se plaindront lorsqu’ils définiront sur un paramètre plus strict que la valeur de retour est ignorée. L’une des choses que je préfère le moins dans une base de code est qu’un développeur résolve l’avertissement en annulant la valeur de retour et en écrivant du code comme :

// ignore la valeur de retour

(vide) I2C_Write(Données);

Si vous allez écrire le commentaire et le code pour faire plaisir au compilateur, vous pouvez tout aussi bien écrire le code à récupérer et vous assurer que tout s’est bien passé :

faire

{

Tentative++ ;

Code d’erreur = I2C_Write(Données);

}while((ErrorCode != SUCCESS) && (Tentative < RETRY_MAX));

Quoi qu’il en soit, je pense que vous voyez l’idée.

Astuce n ° 4 – Utilisez statique pour les variables d’étendue de module

Le langage de programmation C par défaut lancera un extern devant les fonctions et variables qui ne sont pas déclarées statiques. Les développeurs créent souvent des variables en haut d’un module qui seront utilisées tout au long de quelque chose comme :

uint8_t MaVar = 0 ;

Les développeurs débutants ne se rendront souvent pas compte que cette déclaration a un extern implicite devant elle et ressemble vraiment au compilateur comme suit :

extern uint8_t MaVar = 0;

Si une variable ne sera utilisée que dans ce module ou accessible via une fonction d’assistance comme get() ou set(), déclarez la variable comme statique pour limiter sa portée au module :

statique uint8_t MaVar = 0 ;

La même chose doit être faite avec les fonctions qui ne seront pas utilisées en dehors du module. Placez un statique devant eux et ne les mettez pas dans le fichier d’en-tête !

Astuce n°5 – Écrire un logiciel en pensant aux tests

Les systèmes embarqués deviennent extrêmement complexes et il est presque impossible d’effectuer des tests de régression sur un système si cela doit être fait manuellement. Les tests doivent être automatisés, ce qui signifie que les développeurs doivent écrire leur logiciel en pensant aux tests. Idéalement, les tests sont écrits avant le logiciel en utilisant une technique comme le développement piloté par les tests, mais personnellement, je n’espère même pas autant. Dans mon esprit, le simple fait de mettre en place un harnais de test et de développer des tests unitaires après l’écriture d’une fonction est un bon début.

Au fur et à mesure que vous écrivez des logiciels en pensant aux tests, les développeurs remarqueront que le code devient un peu plus abstrait, en couches et les interfaces plus bien définies. Si vous envisagez de tester, cela oblige le logiciel à prendre une certaine forme que j’ai trouvée, ce qui donne des résultats dans une architecture plus propre et peut globalement aider à améliorer la flexibilité, l’évolutivité et toutes ces autres fonctionnalités que nous nous efforçons toujours d’atteindre.

Conclusion

La qualité des applications C semble s’améliorer, mais il existe encore des techniques de base que les développeurs peuvent utiliser pour améliorer rapidement leur propre code. Ici, nous avons examiné quelques-uns des problèmes courants que je rencontre et qui sont assez faciles à corriger. Assurez-vous de prendre le temps de mettre en œuvre ces conseils et vous constaterez que des revues de code et même la robustesse de votre code s’amélioreront.