Pour moi le minimum c'est quand même d'expliquer ce que tu fais et pourquoi tu le fais comme ça.
La description du pourquoi et du comment devrait se trouver avec le prototype ou définition de la fonction et nom dans la fonction elle-meme. Dans le code en lui même, il ne devrait avoir que des commentaires éclairant sur des choses non évidentes à la lecture. Mais les mecs qui mettent des trucs du genre:
if (traitement.res == ECHEC) {
// cas où le traitement à échouer
}
pourrait s'abstenir.
Mais chacun fait comme il veut, perso je préfère parcourir les headers et lire la description de la fonction que me taper la fonction elle même.
[^] # Re: Faire du closed-sources sous licence GPL
Posté par deftones_chris . En réponse au journal Faire du closed-sources sous licence GPL. Évalué à 2.
La description du pourquoi et du comment devrait se trouver avec le prototype ou définition de la fonction et nom dans la fonction elle-meme. Dans le code en lui même, il ne devrait avoir que des commentaires éclairant sur des choses non évidentes à la lecture. Mais les mecs qui mettent des trucs du genre:
if (traitement.res == ECHEC) {
// cas où le traitement à échouer
}
pourrait s'abstenir.
Mais chacun fait comme il veut, perso je préfère parcourir les headers et lire la description de la fonction que me taper la fonction elle même.