• [^] # Re: Bons commentaires

    Posté par . En réponse au journal To comment or not to comment. That is the question.. Évalué à 1.

    Il faut toujours commenter le domaine des arguments acceptés, car en général le type seul ne permet pas déterminer le domaine de la fonction. Il faut aussi commenter les conditions d'erreur, particulièrement celles qui ne sont pas gérées.

    En gros, tu prônes la programmation par contrat?

    Celle-ci permets justement de virer pas mal de commentaires (enfin, pas trop pour le C, vu qu'on ne possède pas certains outils nativement comme les exceptions, mais…):

    "my_structure* returnPointer();"

    my_structure* returnPointer()
    {
    my_structure* ret;

    if(ret==NULL)
    generateSigSegv();
    }

    La, on sait que si on retourne NULL (0) on génère une sigsegv et le programme se plantera. Avant même d'essayer d'utiliser une valeur invalide, et pourtant je ne l'ai commenté nulle part.

    Ensuite, le nom est redondant avec la signature de la fonction: on sait déjà, grâce au code, que la fonction retourne un pointeur… grâce au prototype, on sait même de quel type, d'ailleurs. Par contre, rien ne nous indique sur quoi le pointeur pointe…
    my_structure* getVideoAddress() serait par exemple bien meilleur. On sait qu'on se récupère une adresse vidéo, sous forme d'une instance de type my_structure.