Discussion :

[misstmourt]

Bonjour,

J'aimerai avoir l'avis de la communauté concernant le nombre d'instruction return à utiliser dans une méthode.

Il semble que 2 camps s'affrontent, l'un insistent sur le fait qu'il ne faut qu'une seule instruction return et pour les autres peu importe ca n'a pas grande importance.

Qu'en pensez vous ?

[Robin56]

J'aimerai avoir l'avis de la communauté concernant le nombre d'instruction return à utiliser dans une méthode.

Pourquoi ce débat ? Pour ta culture générale ou dans une situation précise ?

Je dirais pour ma part qu'en général, on limite à 1 return par méthode. Certains cas particulier font que la syntaxe a plusieurs return peut être valable. En tout cas ce qu'il faut limiter, c'est de devoir galérer dans son code pour retrouver où l'on en sort.

[joel.drigo]

Salut,

oui, beaucoup de puristes, en particulier du monde scientifique et/ou enseignant, défendent le return unique. C'est une préconisation de la programmation structurée, et c'est en général une bonne règle à suivre pour éviter les problèmes.

pour ma part je suis ingénieur, et si la plupart du temps j'évite la multiplication des return pour éviter de galèrer lorsque je dois ajouter un traitement supplémentaire (retrouver tout les returns, les mettre à la fin pour éviter la duplication de code (qui est bien pire pour moi que la multiplication des return),
mais bon que je me prends pas la peine qu'en j'écris ce genre de truc :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
public int getTruc(String string) {
    if ( string==null ) {
        return -1;
    }
    if ( string.length()==0 ) {
       return 0;
    }
    ... mon traitement
    return resultat;
}

plutot que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
public int getTruc(String string) {
    int resultat;
    if ( string==null ) {
        resultat = -1;
    }
    else if ( string.length()==0 ) {
       resultat = 0;
    }
    else {
    ... mon traitement
    }
    return resultat;
}

des fois il faut être souple pour éviter de trop compliquer les méthodes : j'ai des cas, ou j'aurais du ajouter 5 bool"ens pour gérer 5 cas de sortir de boucles, ça commençait a devenir ridicule,

en fait, je considère en général, qu'un return en cas de condition de sortie (sur erreur, ou valeur étrange), n'est pas totalement proscrit, sinon je préfère avoir un return unique à la fin. si je commence à devoir avoir des return au milieu de la méthode pour des cas fonctionnels, je subdivise ma méthode : la plupart du temps c'est que le problème peut être subdiviser en sous cas excluant (mais ce n'est pas toujours le cas)

[Influenza]

Bonjour,

Il n'existe pas de réponse précise à cette question.
Pour y répondre, tu peux te baser sur des normes de codage comme par exemple avec l'outil "PMD" (inclus dans Sonar) qui a deux règles sur le "return" :

- Une qui demande un seul "return". La description associée de cette règle :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

A method should have only one exit point, and that should be the last statement in the method.

Par défaut cette règle n'est pas activée.

- Une autre qui impose par défaut 2 "return" maximum :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Restricts return statements to a specified count (default = 2).

Par contre cette règle est activée par défaut et a un niveau de criticité à "majeur".

Mathieu

[professeur shadoko]

Par contre cette règle est activée par défaut et a un niveau de criticité à "majeur".

je serais heureux de voir une justification précise de cette règle... Un demonstration pertinente des méfaits des return multiples serait bienvenue (car je n'en vois pas la raison si ce n'est des raisons historiques venues du fin fond des ages des analyseurs statiques)

[ternel]

En C, c'était utile, parce qu'avoir un unique return permettait de garantir qu'on pouvait libérer toutes les ressources.

En Java (ou C++), à cause des exceptions, on ne peut plus avoir cette considération, vu qu'elles introduisent des points de sorties quasiment incontrolables.

Les garanties de nettoyages sont alors fournies par le try-finally (ou le RAII pour ceux qui font du C++)

Cela dit, la version "légère" de l'antique restriction serait de n'avoir qu'un seul return nominal, les autres point de sortie étant situés tôt dans le code, et servant à controler les conditions de travail.

typiquement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
int premiereDifference(String alpha, String beta) {
    if (alpha==null || beta == null) {
        throw new NullPointerException;
    }
    final int max = Math.min(alpha.length(), beta.length());
    if (max == 0) return max;//cas de sortie rapide
 
    //début des calculs
 
    int index = 0;
    //une longue technique de comparaison modifiant index;
    return index;
}

[tchize_]

je me permet un avantage du return, par rapport à la variable de type "result".

Le return a l'avantage d'être mis en évidence par défaut dans les IDEs, c'est un mot clé.

A contrario, les instruction de type resultat=... sont plus dure à détecter rapidement, ce qui fait des returns multiples une code parfois plus facile à lire.

De plus, si je met dans mon code

return OPERATION_CANCELED, je suis confiant que c'est ce qui est retourné.
Si je met

resultat =OPERATION_CANCELED

je dois vérifier les lignes suivant pour savoir si ça n'a pas été écrasé....


Il y a du pour et du contre pour chaque méthode. Je n'ai jamais, personellement, que suivi autant que possible la règle de la simplicité. Si mes return évitent d'imbriquer 5 ifs entre eux, je prend. Si mon calcul est progressif et complexe, la variable resultat est souvent plus pratique.

A voir au cas par cas donc

[ternel]

L'argument du bon sens est effectivement le meilleur à mes yeux.

[Influenza]

je serais heureux de voir une justification précise de cette règle... Un demonstration pertinente des méfaits des return multiples serait bienvenue (car je n'en vois pas la raison si ce n'est des raisons historiques venues du fin fond des ages des analyseurs statiques)

Franchement aucune idée... Je ne faisais que remarquer que sur une installation par défaut de Sonar, avec le plugin PMD, cette règle est activée par défaut...

Ceci dit, je vois un cas dans lequel je pense qu'il vaudrait mieux éviter le "return" c'est dans une boucle, du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
for (balbla) {
   if (vrai) {
      return ...;
   }
   ...
}

Mathieu

PS : Bon troll le coup du "return"

[Robin56]

PS : Bon troll le coup du "return"

J'aurais cru aussi que c'était un sujet qui allait partir en troll mais finalement non. Je trouve qu'aucun avis ne se contredit vraiment, tout le monde semble faire remarquer des points similaires.

[thelvin]

Ceci dit, je vois un cas dans lequel je pense qu'il vaudrait mieux éviter le "return" c'est dans une boucle, du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
for (balbla) {
   if (vrai) {
      return ...;
   }
   ...
}

Et le remplacer par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
type result = départ;
for (balbla) {
   if (vrai) {
      result = truc;
      break;
   }
   ...
}

?

Pas d'accord. break ne rend pas plus lisible que return, mais return rend plus lisible que break.

Pour éviter la multiplication des cas à traquer, cette boucle devrait sans doute être externalisée dans une méthode avec juste vérification des cas aux limites, return dans la boucle et return après la boucle. Mais si c'est déjà ce qu'elle fait, elle est plus claire comme ça qu'avec break.

[Influenza]

De mon point de vue un "return" dans une boucle est une sortie "brutale" du contexte d’exécution, alors que le break fini juste la boucle. Beaucoup de mes profs d'algorithmie à la fac enseignaient cette approche quelque soit le langage.

Personnellement je n'emploie pas de "return" dans une boucle et j'aime bien l'approche de leternel sur les cas de sortie rapide. Mais ça n'engage que moi

Mathieu

[thelvin]

De mon point de vue un "return" dans une boucle est une sortie "brutale" du contexte d’exécution, alors que le break fini juste la boucle.

"Juste finir la boucle" est une sortie tout aussi brutale du contexte d'exécution.
Mais sans indiquer pour autant où en est pour la suite. Le return nous dit avec quelle valeur on sort, mais le break nous oblige a aller chercher où se termine la boucle, et où en sont les variants de la boucle à ce moment-là. C'est tout un bordel.

Donc, si on considère que ces histoires de sortie brutale du contexte d'exécution sont un problème (pourquoi considèrerait-on ça ?) Alors break et return ont tous les deux le même défaut.
Par contre, return a de la valeur ajoutée par rapport à break, et break n'en a pas par rapport à return.

Donc, quand il est possible d'utiliser return, return est toujours meilleur que break. CQFD.

Beaucoup de mes profs d'algorithmie à la fac enseignaient cette approche quelque soit le langage.

Les miens aussi. Mais depuis j'ai largement dépassé leur niveau sur ces questions. Et en relisant les codes qu'ils nous fournissaient, ou ceux dont ils étaient les auteurs, j'ai compris que c'est parce qu'ils étaient coincés dans des manières naïves et archaïques d'organiser leur code. Quand on fait mauvais, l'emploi de break au lieu de return permet d'avoir du moins mauvais. Mais le mieux est encore d'avoir du bon, et de se poser ces questions ensuite.
Ces façons sont encore en usage pour certains langages et technologies (parfois parce qu'il y a des limites techniques et qu'on fait pas ce qu'on veut.) Mais elles n'ont rien à faire en Java, entre autres, ou dans n'importe quel langage haut niveau. N'en déplaise aux profs qui n'ont plus trop de conseil à me donner.

[tchize_]

m'es d'avis que c'est un héritage de l'époque assembler, C, Fortran et consorts, quand le nettoyage du contexte revêttait une importance particulière et où il fallait s'assurer de remettre les registres / libérer la mémoire correctement avant de remonter dans la pile

[Influenza]

m'es d'avis que c'est un héritage de l'époque assembler, C, Fortran et consorts, quand le nettoyage du contexte revêttait une importance particulière et où il fallait s'assurer de remettre les registres / libérer la mémoire correctement avant de remonter dans la pile

+1. J'avais appris ça à une époque où Java n'existait pas encore vraiment
En effet, en Java, ça n'a plus tellement d'importance...

[professeur shadoko]

N'en déplaise aux profs qui n'ont plus trop de conseil à me donner.

Dieu n'a pas créé les profs: ils sont comme les médecins, les politiciens ou les plombiers-zingueurs : selon notre humeur on peut choisir de mesurer à quel point le verre est plein ou vide
quand j'étais prof je disais toujours que mon objectif était que l'élève dépasse le maître! Donc , si on est optimiste, on dira qu'ils ont réussi

[thelvin]

Je suis tout à fait d'accord. Et d'ailleurs, en termes d'enseignement ou de recherche, je ne doute pas une seconde qu'ils s'en sortent tous mieux que je le ferais. Chacun son truc.

Ces questions de return ne concernent finalement que l'initiation et l'approche d'un nouveau langage, et les profs avaient surtout l'air de bien s'emmerder pendant cette partie du cours.