Maintenant, si ton style de programmation (ou les normes de style que l'on te demande de suivre) vont dans le sens d'utiliser 0 pour signifier faux ou perdu! (dans la ligne générale du langage C), utiliser exit(EXIT_SUCCESS) plutôt que return 0 / exit(0) peut être une bonne option pour la lisibilité générale.
Ma guideline perso: - si c'est cense etre portable: EXIT_SUCCESS/EXIT_FAILURE - si c'est cense faire du POSIX: exit(0); Quand on aura autre chose qu'un exit(0), souvent le code retourne sera specifie quelque part, ou bien ca presentera un interet de le choisir.
Attention a l'idiome (faux) suivant:
int bad = 0;
... if (problem) bad++;
exit(bad);
qui ne va marcher correctement que si bad % 256 != 0...
In article <j03g0r$fcb$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
Maintenant, si ton style de programmation (ou les normes de style que
l'on te demande de suivre) vont dans le sens d'utiliser 0 pour signifier
faux ou perdu! (dans la ligne générale du langage C), utiliser
exit(EXIT_SUCCESS) plutôt que return 0 / exit(0) peut être une bonne
option pour la lisibilité générale.
Ma guideline perso:
- si c'est cense etre portable: EXIT_SUCCESS/EXIT_FAILURE
- si c'est cense faire du POSIX: exit(0);
Quand on aura autre chose qu'un exit(0), souvent le code retourne sera
specifie quelque part, ou bien ca presentera un interet de le choisir.
Attention a l'idiome (faux) suivant:
int bad = 0;
...
if (problem)
bad++;
exit(bad);
qui ne va marcher correctement que si bad % 256 != 0...
Maintenant, si ton style de programmation (ou les normes de style que l'on te demande de suivre) vont dans le sens d'utiliser 0 pour signifier faux ou perdu! (dans la ligne générale du langage C), utiliser exit(EXIT_SUCCESS) plutôt que return 0 / exit(0) peut être une bonne option pour la lisibilité générale.
Ma guideline perso: - si c'est cense etre portable: EXIT_SUCCESS/EXIT_FAILURE - si c'est cense faire du POSIX: exit(0); Quand on aura autre chose qu'un exit(0), souvent le code retourne sera specifie quelque part, ou bien ca presentera un interet de le choisir.
Attention a l'idiome (faux) suivant:
int bad = 0;
... if (problem) bad++;
exit(bad);
qui ne va marcher correctement que si bad % 256 != 0...
Antoine Leca
Marc Espie écrivit :
Ma guideline perso: - si c'est cense etre portable: EXIT_SUCCESS/EXIT_FAILURE - si c'est cense faire du POSIX: exit(0); Quand on aura autre chose qu'un exit(0), souvent le code retourne sera specifie quelque part, ou bien ca presentera un interet de le choisir.
Oui, c'est logique, et plus détaillé que ce que j'avais décrit.
Ce que voulais souligner, c'est l'importance d'avoir une référence (norme de style ou autre) pour ce genre de chose. Parce que la norme C, elle, ne fixe pas de règle pour associer une signification spécifique à chaque formulation (comme en témoigne la question originale.)
Antoine
Marc Espie écrivit :
Ma guideline perso:
- si c'est cense etre portable: EXIT_SUCCESS/EXIT_FAILURE
- si c'est cense faire du POSIX: exit(0);
Quand on aura autre chose qu'un exit(0), souvent le code retourne sera
specifie quelque part, ou bien ca presentera un interet de le choisir.
Oui, c'est logique, et plus détaillé que ce que j'avais décrit.
Ce que voulais souligner, c'est l'importance d'avoir une référence
(norme de style ou autre) pour ce genre de chose. Parce que la norme C,
elle, ne fixe pas de règle pour associer une signification spécifique à
chaque formulation (comme en témoigne la question originale.)
Ma guideline perso: - si c'est cense etre portable: EXIT_SUCCESS/EXIT_FAILURE - si c'est cense faire du POSIX: exit(0); Quand on aura autre chose qu'un exit(0), souvent le code retourne sera specifie quelque part, ou bien ca presentera un interet de le choisir.
Oui, c'est logique, et plus détaillé que ce que j'avais décrit.
Ce que voulais souligner, c'est l'importance d'avoir une référence (norme de style ou autre) pour ce genre de chose. Parce que la norme C, elle, ne fixe pas de règle pour associer une signification spécifique à chaque formulation (comme en témoigne la question originale.)