Plusieurs return pour une fonction

Bonjour

J'aimerai avoir des avis sur la possibilité de mettre plusieurs return dans une fonction.

Je trouve ça très pratique, ça allège le code, mais certains disent que ça gène pour le débogage. Donc, il faudrait ne mettre qu'un return par fonction :(

Un exemple :

Code:

---

1 2 3 4 5

unsigned long fact(unsigned short n) { if (n<2) return 1; return n*fact(n-1); }

---

Ou

Code:

---

1 2 3 4 5 6 7 8 9

unsigned long fact(unsigned short n) { unsigned long f;   if (n<2) f=1; else f=n*fact(n-1);   return f; }

---

Bonsoir,

Je pense que cela dépend de la fonction. Si une fonction possèdent beaucoup de points de sortie (sur plus d'une vingtaine de lignes), cela commence à être coton à débugger.
Maintenant, pour une fonction de quelques lignes, cela ne pose pas de problème.

Il m'arrive de faire une boucle do { } while(0) et de mettre à jour une variable locale de sortie et de "casser" cette boucle par un break. C'est une autre façon de faire.
J'avoue que je me laisse tenter de mettre des returns dans mes fonctions une fois qu'elles ont été validées.

Code:

---

1 2 3 4

unsigned long fact(unsigned short n) { return (n<2)?1:n*fact(n-1) ; }

---

Salut,

Au niveau du debug, c'est surtout gênant en embarqué car les differents optimiseurs tentent de factoriser ces returns. Du coup, en pas à pas, le déroulement affiché et la réalité ne correspondent plus. On peut galérer un moment avant de comprendre que c'est la faute de l'optimiseur. Mais il y a des directives de compilations qui l'inhibent. Généralement on active l'optimiseur en mode release mais pas en mode debug.

Ça peut également nuire à la lisibilité, mais je comprends que ce n'est pas le concept le plus intéressant quand on débute.

A+

Pfeuh

Citation:

---

mais certains disent que ça gène pour le débogage

---

Ah !! Je ne vois pas dans le cas de plusieurs return, mais c'est vrai quand on met une fonction dans le return.

A mon ancien boulot, on avait 1 return par fonction (en général), c'était pour tracer à 1 seul endroit le retour de la fonction.

Quelle est la meilleure solution ? Mettre plusieurs return ou un seul ? Avec 1 seul, il y aura obligatoirement des "goto end;" pour les grosses fonctions. Le goto provoque d'autres soucis.

Donc, je dirais : mieux vaut mettre plusieurs return.

Bonjour à tous

Dans ma société, nous avons définis des règles de codages , dont une qui stipule qu'il ne peut y avoir qu'un seul return dans une fonction.

Lorsque l'on utilise un logiciel comme QAC ou PCLINT, le fait d'avoir plusieurs return dans une fonction génère un message d'erreur.

L'objectif est d'éviter l'oublie d'un return. Dans le cas d'une fonction simple, cela a peu d'intérêt car on le voit facilement, dans le cas de fonctions complexe avec un grand nombre de if .. else if .. il est facile d'en oublier un.

1. En php ( en général avec les interpréteurs), il n'y a pas de vérification que tous les chemins renvoient une valeur.
2. C'est vrai qu'il y a parfois des problèmes de lisibilités.
3. Surtout cela va à l'encontre du concept de programmation structurée ( cela revient à faire un GOTO !).

Citation:

---

Avec 1 seul, il y aura obligatoirement des "goto end;" pour les grosses fonctions.

---

Il ne devrait pas y avoir de "grosses fonctions" ! Faire un return ...; et faire un "goto end;" c'est la même chose !

Comme toujours, faire appel à son bon sens. Parfois une fonction est plus claire, ou plus sure, ou plus lisible, ou plus maintenable, en ayant un seul return. Parfois c'est l'inverse.

Ce ne sont pas les règles de codage qui font le bon code, c'est le programmeur.

Bonjour

Code:

---

Ce ne sont pas les règles de codage qui font le bon code, c'est le programmeur.

---

Dans l'industrie, c'est faux. Les règles ne sont pas faites que pour embêter les gens, mais surtout pour augmenter la qualité du code, standardiser l'écriture pour rendre le code plus lisible, pour la portabilité, et j'en oublie plein d'autre.

De plus nos client relisent ces règles de codage et viennent vérifier qu'elles sont réellement appliquées (et il vaut mieux quelles le soient).

J'ai connus des super programmeur de génie dont les soft sont tombés dans l'oublie car immaintenable en leur absence.

Citation:

---

Envoyé par Elijha

Code:

---

1 2 3 4

unsigned long fact(unsigned short n) { return (n<2)?1:n*fact(n-1) ; }

---

---

Oui, mais là, je largue presque 100% de mes étudiants !

Citation:

---

Envoyé par Elijha

Code:

---

1 2 3 4

unsigned long fact(unsigned short n) { return (n<2)?1:n*fact(n-1) ; }

---

---

Salut

Personnellement je préfère mettre en premier le cas le plus souvent (statistiquement) exécuté

Code:

---

1 2 3 4

unsigned long fact(unsigned short n) { return (n>1)?n*fact(n-1) :1; }

---

Sinon pour l'histoire des return, je pense que ce qui nuit à la qualité d'un code ce sont les extrémistes de tous bords. Autant on peut avoir une belle fonction facile à comprendre parce que justement les sorties impromptues sont gérées au début ce qui donne ensuite un code plus simple ; autant un autre cas sera mieux traité si le return est centralisé en final. Mais affirmer de façon péremptoire "il faut" ou "il ne faut pas" c'est faire montre de beaucoup de vanité. L'important c'est de bien "sentir" son code tout en prenant aussi en compte les autres critères éventuels comme le travail collaboratif, les demandes client, la compréhension par les outils annexes...

Merci à tous !

J'ai l'impression que la bonne réponse est une réponse à la normand. P't-être ben oui, p't-ëtre ben qu'non !

Toutes vos remarques sont intéressantes.

Et pour ce code ? Vous dites quoi ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

signed char est_premier(unsigned long nb) { unsigned long i;   if (nb<2) return 0; if (nb==2) return 1; if (nb%2==0) return 0;   for (i=3;i*i<=nb;i+=2) { if (nb%i==0) return 0; }   return 1; }

---

Citation:

---

Envoyé par troumad

Et pour ce code ? Vous dites quoi ?

---

J'aime bien, il est lisible. Les conditions sont énoncées comme le ferait un humain. C'est cependant ce multiple return précisément qui pose des problèmes de débogage en embarqué (comprendre "compilateur avec optimiseur poussé"). L'essentiel étant à mon sens d'en être conscient, car l'optimiseur se configure facilement.

[edit] De plus quand on voit la complexité pour coder une version avec un seul return, on se demande vraiment si le jeu en vaut la chandelle. [/edit]

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55

#include <assert.h> #include <stdio.h>   int est_premier(unsigned long nb) { unsigned long i; int result;   switch(nb) { case 0: case 1: result = 0; break; case 2: result = 1; break; default: result = 1; if(nb%2 == 0) { result = 0; } else { for (i=3; i*i<=nb; i+=2) { if (nb%i==0) { result = 0; break; } } } break; } return result; }   int main(int argc, char** argv) { assert(est_premier(0) == 0); assert(est_premier(1) == 0); assert(est_premier(2) == 1); assert(est_premier(3) == 1); assert(est_premier(4) == 0); assert(est_premier(10) == 0); assert(est_premier(11) == 1); assert(est_premier(13) == 1); assert(est_premier(17) == 1); assert(est_premier(941) == 1); assert(est_premier(942) == 0); return 0; }

---

A+

Pfeuh

C'est bien pour cette raison que j'avais opté pour plusieurs return !

Citation:

---

[edit] De plus quand on voit la complexité pour coder une version avec un seul return, on se demande vraiment si le jeu en vaut la chandelle. [/edit]

---

On peut faire plus court avec un seul return et en suivant la même logique :

Code:

---

1 2 3 4 5 6 7

int estPremier(unsigned int nb) { unsigned int i; int premier = nb%2 != 0; for (i=3; i*i<=nb && premier; i+=2)premier = nb%i != 0; return nb >= 2 && (nb == 2 || premier); }

---

Là, c'est génial pour planter mes étudiants du premier coup...
En plus, il y a du int, et c'est complètement déconseillé dans les programmations sécurisées.

Citation:

---

Envoyé par troumad

Là, c'est génial pour planter mes étudiants du premier coup...

---

Exact. Mais au coup suivant ils font un petit effort et se mettent à apprécier. Ou au-moins à comprendre.

Citation:

---

Envoyé par troumad

En plus, il y a du int, et c'est complètement déconseillé dans les programmations sécurisées.

---

Bah, là aussi il faut voir le contexte. Déjà Diogène a juste voulu montrer un exemple d'une fonction à la fois programmée de façon soft et ne contenant tout de même qu'un seul return et a mis "int" sans penser à la sécurisation. De plus, le int ici sert juste de booléen et n'aura aucun effet de bord non désiré...

Citation:

---

Envoyé par Sve@r

Exact. Mais au coup suivant ils font un petit effort et se mettent à apprécier. Ou au-moins à comprendre.

---

Euh... Certains ont encore des problèmes avec le printf :(
Je ne forme pas des informaticiens, mais j'apprends un peu d'informatique à des personnes qui feront par exemple de l'électrotech !

Citation:

---

Envoyé par Sve@r

le int ici sert juste de booléen et n'aura aucun effet de bord non désiré...

---

Il y a aussi les unsigned int nb et i qui sont là pour le travail sur le nombre...

Sve@r a bien analysé le code (je n'est pas utilisé les _Bool par souci de compatibilité avec des compilateurs non C99)

Ce n'était pas à destination d'étudiants débutants (ni une critique des codes proposés précédemment) mais juste un exercice de style sur l'utilisation des booléens. On peut bien s'amuser un peu !

J'ai du rater le memo, quelqu'un peut m'expliquer en quoi les int sont dangereux ?

Citation:

---

Envoyé par matafan

J'ai du rater le memo, quelqu'un peut m'expliquer en quoi les int sont dangereux ?

---

Tu me rassures.
Moi qui craignais d'être le seul à ne pas avoir compris... :aie: