Convention du code de retour.

Version imprimable

08/01/2013, 00h29
Lyyn-

Convention du code de retour.

Je suis actuellement en plein conflit intérieur et extérieur (avec mon prof de prog.). J'ai fait des recherches mais soit j'suis pas chanceux, soit j'suis totalement débile. En tout cas, j'trouve rien :<

Mon problème ? J'voudrais simplement savoir... Quand on exécute une fonction qui envoie un code de retour, dans ma réflexion, si tout s'est bien déroulé, la fonction fait un return 0 (ou False quoi), et si une erreur a été interceptée, un return 1 (donc True) serait envoyé.
Ne me parlez pas des raise, svp. Restons dans ce sujet bien précis 8-)

Je trouve ça logique, en fait. Alors mon "rival" pour ainsi dire m'explique que je dois mettre 1 au lieu de 0 car, par exemple, if(a == a): renverra True, donc 1.

Heu ouais, ça me convaincs absolument pas. DONC. Est-ce qu'il existe une convention ou pas ? J'ai fait des recherches sur Google, je n'ai rien trouvé de bien. J'en ai fait dans les fichiers de Python et là par contre je tombe sur 2-3 trucs qui confirment ce que je pensais de base, cependant ça peut tout aussi bien être un hasard.

codecs.h ~ L149 - 154 (de Python3.2)

Citation:

/* Register the error handling callback function error under the given
name. This function will be called by the codec when it encounters
unencodable characters/undecodable bytes and doesn't know the
callback name, when name is specified as the error parameter
in the call to the encode/decode function.
Return 0 on success, -1 on error */

Qu'en pensez-vous ? :3
08/01/2013, 08h04
emmanuel_dumas

Bonjour

Il n'y a pas de convention acceptée par tous sur ce sujet.

Il y a une habitude unix : valeur positive pour un bon déroulement, -1 pour une erreur.

Ce genre de convention est en général décidée au niveau du projet ou de l'équipe. En prenant en compte du contexte exact du projet, on trouve souvent une solution assez élégante. Mais il s'agit surtout d'une convention : c'est à dire que la plus important soit que le point de vu soit partagé par toute l'équipe et qu'il soit adopté.
Dans ces cas, je m'attache à toujours remonter le maximum d'information, sans surcout de ressources. Ainsi j'aime bien la convention : valeur positive pour un bon déroulement, valeur négative pour une erreur. Ensuite, la valeur négative change en fonction du type d'erreur.

Cordialement
Emmanuel
08/01/2013, 08h33
pfeuh
Salut,

C'est celui qui écrit la fonction qui décide de ce qu'elle doit retourner et qui doit bien sûr le documenter. Ça peut être un flag: 0 ou différent de zéro, un entier: 0 signifiant dans ce cas succès et différent de zéro donnant le code d'erreur. D'un autre côté, une fonction "isDigit" indiquant qu'un caractère fait partie de "0123456789" devrait logiquement retourner un zéro quand le test n'est pas concluant. Du coup, on comprend facilement des bouts de code comme:
Code:

1 2 3 4 5 6 7 8 if (isDigit(mychar)) { /* traitement pour les caracteree 0123456789 */ } else { /* traitement pour les autres caracteres */ }
Pour ce qui est des OS, je ne connais que windows, et les programmes retournent des entiers signés à l'OS, 0 signifiant succès et une valeur différente de 0 étant le code d'erreur.

A+

Pfeuh
08/01/2013, 08h49
plxpy
Soyons précis (mais ici, tout est affaire de précision) :

Citation:

Il y a une habitude unix : valeur positive pour un bon déroulement, -1 pour une erreur.

Je lis Unix (et pas C sous Unix), je comprends donc shell / interpréteur. Non, les codes retour sous le shell ne sont pas signés. Aucune chance de donner une quelconque signification à un code retour négatif qui ne sera jamais retourné, même quand on l'écrit explicitement :
Code:

1 2 3 4 5 6 7 8 plx@sony:~$ more shell_script.sh exit -1 plx@sony:~$ chmod +x shell_script.sh plx@sony:~$ plx@sony:~$ ./shell_script.sh plx@sony:~$ echo $? 255 plx@sony:~$
Cela dit, 0 sous Unix est "conventionnellement" synonyme de "tout s'est bien passé". Quand il faut préciser des erreurs (ou de simples impossibilités de lancer le traitement), on n'a que des valeurs positives pour faire le distingo
08/01/2013, 15h00
wiztricks

Salut,

Citation:

Envoyé par Lyyn-

Quand on exécute une fonction qui envoie un code de retour, dans ma réflexion, si tout s'est bien déroulé, la fonction fait un return 0 (ou False quoi), et si une erreur a été interceptée, un return 1 (donc True) serait envoyé.
Ne me parlez pas des raise, svp. Restons dans ce sujet bien précis 8-)

Ne pas parler des exceptions, c'est ignorer l'apport de la POO sur le sujet.
Un de ses apports est justement de ne plus avoir à définir et documenter ce genre de standard ni de faire la police pour s'assurer que les développeurs le respectent.
Les développeurs peuvent donc omettre de tester les statuts de retour et laisser l'application se vautrer avec un minimum de diagnostic.
Plus besoin de remonter à la cause de la cause de la cause: le glandu qui a omis de tester le code de retour de l'appel à la lecture de la socket et rempli la BDD avec des enregistrements corrompus.
- W
08/01/2013, 20h33
Lyyn-
Citation:
Envoyé par pfeuh

Salut,

C'est celui qui écrit la fonction qui décide de ce qu'elle doit retourner et qui doit bien sûr le documenter. Ça peut être un flag: 0 ou différent de zéro, un entier: 0 signifiant dans ce cas succès et différent de zéro donnant le code d'erreur. D'un autre côté, une fonction "isDigit" indiquant qu'un caractère fait partie de "0123456789" devrait logiquement retourner un zéro quand le test n'est pas concluant. Du coup, on comprend facilement des bouts de code comme:

Code:

1 2 3 4 5 6 7 8 if (isDigit(mychar)) { /* traitement pour les caracteree 0123456789 */ } else { /* traitement pour les autres caracteres */ }

Pour ce qui est des OS, je ne connais que windows, et les programmes retournent des entiers signés à l'OS, 0 signifiant succès et une valeur différente de 0 étant le code d'erreur.

A+

Pfeuh
Ouais, c'est un peu dans cet ordre d'idée que je me range aussi... Par contre je trouve ça étonnant qu'il n'existe pas de convention à ce niveau :p

Merci beaucoup pour vos réponses !

@wiztricks: Dans le cadre de l'enseignement, on ne parle pas directement de la POO, des raise, assert etc. On commence simple, donc on passe forcément par l'étape des codes de retour. C'est pourquoi j'ai demandé d'éviter de parler de ça, on risque de s'égarer inutilement :p

Mais je suis tout à fait d'accord avec toi sinon :)
09/01/2013, 15h56
wiztricks

Salut,

Citation:

Envoyé par Lyyn-

Ouais, c'est un peu dans cet ordre d'idée que je me range aussi... Par contre je trouve ça étonnant qu'il n'existe pas de convention à ce niveau :p

A partir du moment ou le langage propose des exceptions, une telle convention est inutile: voilà qui devrait vous étonner.

Ceci dit votre collègue a raison: si on doit interpréter le statut de retour d'une fonction comme un booléen (True/False), il est logique et préférable de traduire OK par True et KO par False.
D'autant qu'en Python une fonction retournera par défaut None qui sera aussi évalué False: "if func()" sera moins ambigu côté OK qu'un "if not func()".

La ou çà coince, c'est que la programmation est un ensemble de pratiques construites à partir de nécessités en décalage avec la logique et le bon sens.
La nécessité est que l'appelant voudra aussi récupérer un indicateur en cas de retour KO pour afficher ou gérer l'erreur.
Si la fonction ne retourne qu'un booléen, il faudra que l'appelé puisse récupérer cet indicateur via un autre canal: par exemple une variable globale comme le propose errno dans le cas de la libc.

Une simplification est de décréter qu'une fonction retournera un code d'erreur. Ce code sera généralement un symbole EXIT_SUCCESS, EXIT_FAILURE, EACCES, ... Ce qui oblige l'appelant à récupérer la définition de ces symboles pour les utiliser et non de tester directement leur valeur.
Mais obtenir des programmeurs qu'ils bossent proprement est coûteux.
Rendre équivalent "OK <=> False <=> 0" permettra de réduire les omissions du test élémentaire plus aisément.

Impossible de faire "convention" voire un "standard" une telle accumulation de mauvaises pratiques! D'autant que les multiples dimensions de ce "problème" sont résolues par les mécanismes d'exception disponibles, dans la plupart des langages, depuis plus de 30 ans.

Citation:

Dans le cadre de l'enseignement, on ne parle pas directement de la POO, des raise, assert etc. On commence simple, donc on passe forcément par l'étape des codes de retour. C'est pourquoi j'ai demandé d'éviter de parler de ça, on risque de s'égarer inutilement

Une fonction est semblable à une fonction mathématique: elle retourne un résultat suivant la valeur des paramètres passés. Elle n'ont pas d'état: mêmes valeurs en entrées même résultat en sortie.
Les fonctions add, sum, factorielle sont simple à écrire et à composer: - écrire = add(add(2,3), 4).

Un statut de retour est rarement un résultat. Pour le récupérer, il faudra passer par des variables globales. Cette dépendance entre la fonction et des variables globales ne la rend plus "simple": comment allez vous composer de telles fonctions?

De plus éviter de parler des exceptions en utilisant un langage comme Python: elles devront être comprises et gérées assez vite. ET vous n'êtes pas obligé d'ouvrir la boîte POO pour en parler.

- W