Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 7 sur 7
  1. #1
    Invité de passage
    Homme Profil pro Lyyn Mayako
    Étudiant
    Inscrit en
    mars 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Nom : Homme Lyyn Mayako
    Âge : 24
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2012
    Messages : 11
    Points : 3
    Points
    3

    Par défaut 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

    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)
    /* 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

  2. #2
    Membre régulier
    Profil pro Emmanuel DUMAS
    Inscrit en
    novembre 2008
    Messages
    103
    Détails du profil
    Informations personnelles :
    Nom : Emmanuel DUMAS

    Informations forums :
    Inscription : novembre 2008
    Messages : 103
    Points : 84
    Points
    84

    Par défaut

    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

  3. #3
    Membre Expert
    Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    mars 2006
    Messages
    827
    Détails du profil
    Informations personnelles :
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : Industrie

    Informations forums :
    Inscription : mars 2006
    Messages : 827
    Points : 1 145
    Points
    1 145

    Par défaut

    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

  4. #4
    Membre Expert Avatar de plxpy
    Homme Profil pro
    Ingénieur
    Inscrit en
    janvier 2009
    Messages
    561
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : janvier 2009
    Messages : 561
    Points : 1 020
    Points
    1 020

    Par défaut

    Soyons précis (mais ici, tout est affaire de précision) :

    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

  5. #5
    Expert Confirmé Sénior
    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2008
    Messages
    4 748
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 4 748
    Points : 7 160
    Points
    7 160

    Par défaut

    Salut,

    Citation Envoyé par Lyyn- Voir le message
    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
    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
    Architectures Post-Modernes

  6. #6
    Invité de passage
    Homme Profil pro Lyyn Mayako
    Étudiant
    Inscrit en
    mars 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Nom : Homme Lyyn Mayako
    Âge : 24
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2012
    Messages : 11
    Points : 3
    Points
    3

    Par défaut

    Citation Envoyé par pfeuh Voir le message
    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

  7. #7
    Expert Confirmé Sénior
    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2008
    Messages
    4 748
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 4 748
    Points : 7 160
    Points
    7 160

    Par défaut

    Salut,

    Citation Envoyé par Lyyn- Voir le message
    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.

    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
    Architectures Post-Modernes

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •