Conventions et propreté du code

Conventions et propreté du code

by Jonathan Bereyziat -
Number of replies: 4

Bonjour,

Lors de la relecture de notre code nous avons relevé quelques questions :

  1. Pour les switch utilisés en C d'après ce post sur stackoverflow il est nécessaire d'avoir un default case, mais je me demandais si il était nécessaire de l'implémenter même si on couvre tous les cas. Comme pour les flags par exemple. Pour le moment nous avons mit un default case qui return une ERR_BAD_PARAMETER ...
  2. Dans plusieurs fonctions nous sommes amené à vérifier si un pointeur est non NULL avec une structure tel que "if (ptr != NULL)..." est-ce que c'est une bonne pratique de vérifier cette condition en utilisant que NULL est en fait que des 0 dans la mémoire et est donc évalué à false dans un if  " if (ptr) ..." ? Ou cela perd trop en lisibilité ?
  3. Enfin sur le forum il y plusieurs posts qui concernent le return d'erreur dans le cas des fonctions void mais les réponses semblent se contredire... Finalement pour les fonctions qui on le type de retour void est-ce que c'est une bonne pratique d'utiliser les macro tel que M_REQUIRE_NON_NULL, malgré le fait que CLION soit très fâché si on le fait :) ?

Merci beaucoup

Jonathan Bereyziat

In reply to Jonathan Bereyziat

Re: Conventions et propreté du code

by Antoine Mehdi De Gendt -

Bonjour,

1. Comme indiqué dans ce post moodle : https://moodlearchive.epfl.ch/2019-2020/mod/forum/discuss.php?d=33551, en C les enums sont encodées à l'aide de nombres entiers. Il faut donc bien ajouter un default case au cas où l'entier donné à la fonction ne correspond pas à une valeur de l'enum. Aussi, dans alu.c pour get_flag il est indiqué qu'il faut retourner 0 si le flag reçu n'est pas valable.

2. Je pense qu'utiliser if(ptr != NULL) est plus lisible, surtout qu'écrire if(ptr) ne simplifie pas vraiment le code.

3. La macro M_REQUIRE_NON_NULL ne peut pas être utilisée dans une fonction qui retourne void car son but est de retourner un code d'erreur si l'argument passé est nul. Comme la fonction retourne void, il est impossible de retourner un code d'erreur (int). Pour gérer un cas comme celui-là, il est possible de procéder à une vérification simple avec un if, et return directement si le ptr est NULL par exemple.

Est-ce que cela répond à toutes vos interrogations ?

Antoine De Gendt

In reply to Jonathan Bereyziat

Re: Conventions et propreté du code

by Jean-Cédric Chappelier -

dans votre point 3, pourquoi dites vous que les réponses semblent se contre-dire ?
Je tiens à clarifier si tel vous semble être le cas.

In reply to Jean-Cédric Chappelier

Re: Conventions et propreté du code

by Jonathan Bereyziat -

Bonjour, 

ma confusion viens des différentes réponses qu'on a eu venant des assistants mais aussi de ces deux posts sur le forum :

  • Dans le premier il est dit que pour les fonctions au retour void il est préférable d'utiliser les macros tel que M_REQUIRE ou M_EXIT qui si je ne me trompe pas renvoient des codes d'erreurs
  • Dans le second il est dit que pour les fonctions outil (=  de bas niveau) donc si je comprend bien cela concerne également les fonctions de bit.c ou alu.c,  il est spécifié qu'on fait confiance aux vérifications de plus haut niveau et qu'il n'est alors pas conseillé d'utiliser les macro mais plutôt d'inclure une condition à exécution pour se prémunir contre nos propres erreurs.

Merci pour votre aide 

Jonathan :)


In reply to Jonathan Bereyziat

Re: Conventions et propreté du code

by Jean-Cédric Chappelier -

Merci pour votre travail d'archiviste !
En effet, à la relecture, le premier message est ambigu : pour Yacine et moi, il était clair que pour l'utilisation des macros, nous ne parlions que des fonctions retournant des codes d'erreur (puisque justement les macros de error.h retournent un int), mais il est vrai que le contexte de la question de départ incluait les 2 (il y a dans alu.c des fonctions « de plus haut niveau » qui retournent des codes d'erreur) et que la réponse finale par rapport au warning n'est pas assez claire.
Désolé pour la confusion et merci donc d'avoir demandé clarification.

Pour insister : il est impératif que toutes les fonctions, sans exception, respectent leur prototype (et donc compilent SANS warning à ce sujet) et, en particulier, retournent le type attendu.
[ Sinon, finalement, à quoi sert un prototype ? ;-) ]