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;
}

[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"