Discussion :

[Sallie]

Bonsoir tout le monde,

Il y'a une question qui me trotte dans la tête depuis un moment. Voilà je fais par habitude mes recherches ou autres itérations de la façon suivante :

1:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
public PosteBudgétaire getPoste(String s){
		boolean trouvé=false;
		PosteBudgétaire posteBudgétaireARetourner=null;
		PosteBudgétaire posteBudgétaire;
		Iterator ite = postes.iterator();
		while(ite.hasNext() && !trouvé){
			posteBudgétaire = (PosteBudgétaire) ite.next();
			if( posteBudgétaire.getLabel().compareToIgnoreCase(s)==0 ){
				trouvé=true;
				posteBudgétaireARetourner=posteBudgétaire;
			}
		}
		return posteBudgétaireARetourner;
	}

Il me semblait qu'un professeur m'avait recommandé de ne jamais mettre plusieurs return. Pourtant en réfléchissant le mettre de mettre un return avt permet de sortir de la boucle plus tôt si l'objet est trouvé. Et en plus sur les exemples de codes rencontrés sur le net c'est souvent l'autre façon

ce qui donnerait

2:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
	public PosteBudgétaire getPoste(String s){
		PosteBudgétaire posteBudgétaire;
		Iterator ite = postes.iterator();
		while(ite.hasNext()){
			posteBudgétaire = (PosteBudgétaire) ite.next();
			if( posteBudgétaire.getLabel().compareToIgnoreCase(s)==0 ){
				return posteBudgétaire;
			}
		}
		return posteBudgétaire;
	}

Quelle méthode est donc meilleure syntaxiquement? la 1 ou la 2?

merci d'avance =)

[Romain B.]

Pour ma part, je préfère la première car je n'aime pas non plus mettre plusieurs return dans une fonction.

[mavina]

Coucou,

la deuxième sans hésitation.

Le return te permet d'éviter de continuer l'itération pour rien. Tu as trouvé, tu retournes. C'est comme ci tu cherchais apres quelque chose, que tu le trouvais dans une étagere mais que tu continuais à chercher dans les autres...

F.

[Sanguko]

Par contre, ca s'ecrit plutot comme ca :

Code :

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

1
2
3
4
5
6
7
8
9
10
public PosteBudgétaire getPoste(String s){
  Iterator ite = postes.iterator();
  while(ite.hasNext()){
    PosteBudgétaire posteBudgétaire = (PosteBudgétaire) ite.next();
    if( posteBudgétaire.getLabel().compareToIgnoreCase(s)==0 ){
	return posteBudgétaire;
    }
  }
  return null;
}

Mais c'est surtout une histoire de gout.

[T`lash]

Moi aussi je préfère la solution des return, mais il en existe une autre ; plutôt que ta variable trouvé tu peux utiliser un break.

[GanYoshi]

Je crois que les breaks sont aussi très déconseillés...

Je pense que la meilleur façon est de faire comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public PosteBudgétaire getPoste(String s){
		PosteBudgétaire posteBudgétaire;
                PosteBudgétaire posteBudgétaireARetourner = null;
		Iterator ite = postes.iterator();
                boolean trouve = false;
		while(ite.hasNext() && trouve == false){
			posteBudgétaire = (PosteBudgétaire) ite.next();
			if( posteBudgétaire.getLabel().compareToIgnoreCase(s)==0 ){
                                posteBudgétaireARetourner = posteBudgétaire;
                                trouve = true;
			}
		}
		return posteBudgétaireARetourner ;
	}

De cette manière, on ne continue pas à chercher alors qu'on a pas trouvé, et on n'utilise pas plusieurs return....
Mais dans la pratique, je mettrais plusieurs return, puisque la fonction est petite et donc facilement compréhensible.

[elmor]

Idem je vote pour la seconde et particulièrement pour la solution de Sanguko.

[Napalm51]

Par contre, ca s'ecrit plutot comme ca :

Code :

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

1
2
3
4
5
6
7
8
9
10
public PosteBudgétaire getPoste(String s){
  Iterator ite = postes.iterator();
  while(ite.hasNext()){
    PosteBudgétaire posteBudgétaire = (PosteBudgétaire) ite.next();
    if( posteBudgétaire.getLabel().compareToIgnoreCase(s)==0 ){
	return posteBudgétaire;
    }
  }
  return null;
}

Mais c'est surtout une histoire de gout.

Je prendrais cette solution aussi :p même si j'ai toujours cette grosse voix d'un prof d'IUT dans la tête qui me dit : "Une fonction, un return !" méthode monsieur, une méthode

[Bezout]

Idem je vote pour la seconde et particulièrement pour la solution de Sanguko.

+1
C'est ce que je fais également.

Au final c'est vrai que c'est de la syntaxe. L'important est de ne pas tout parcourir si on trouve.

[themadmax]

Ah, je suis content de tomber sur ce poste!
Voila moi je suis un adepte du return, et j'ai aussi entendu du mal de lui!
Parcontre on ne ma jamais dit aucun argument!

Donc j'exprime les miens pour le return :

• Quand on trouve l'item, on sort directement on sait que rien d'autre ne sera fait pas la suite (parfois loin dans la fonction). On retourne directement l'objet trouvé, qui parfois n'est plus valable en dehors de la boucle.
• Simplicité de code : rajouter un boolean dans un for ou un while je trouve cela pas très visible, et biensur qui dit rajout de code dit rajout potentiel de bug!
• Lors de 15 conditions dans une fonction on se retrouve avec un bon nombre d'indentation si on ne fait pas des return à chaque condition.
• En C le code generé est plus long (rajout d'une condition) ce qui pour des grande recherche peut s'averer un peu plus couteux.

[OButterlin]

Solution 2, idem Sanguko, voir encore plus compacte... (mais là c'est du détail)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
public PosteBudgétaire getPoste(String s)
{
  Iterator ite = postes.iterator();
  while(ite.hasNext())
  {
    PosteBudgétaire posteBudgétaire = (PosteBudgétaire)ite.next();
    if( posteBudgétaire.getLabel().compareToIgnoreCase(s) == 0 ) return posteBudgétaire;
  }
  return null;
}

Dans tous les cas, il est (à mon avis) toujours préférable de privilégier la lisibilité, et n'en déplaise aux profs, plusieurs points de retour (return) dans une méthode (ou fonction) rendent le code plus aéré...
En plus, la pluspart des EDI mettent le return en couleur... hyper lisible !

Il ne faut pas confondre "une fonction, une seule valeur retournée" avec "une fonction, un retour"

Ce n'est que mon avis...
A+

[T`lash]

Les profs sont souvent des vieux de la vieille qui ont connu des langages trop peu permissifs et ils enseignent tel qu'ils ont appris.
Mais l'époque des cartes à trous et des switches binaires est dépassée.
Les nouveaux langages proposent des mécanismes afin de simplifier la vie des programmeurs alors autant s'en servir.

Les raisons qui motivent les détracteurs des return multiples et ceux du break sont les mêmes : c'est en général un question de clareté du code parce que ce n'est pas une habitude de programmation (les autres raisons qu'il pouvait y avoir ne sont plus vraies grâce à l'évolution des compilateurs).
Si c'est bien fait et qu'on en connait le fonctionnement cela peut au contraire rendre le code plus lisible.

[mavina]

Salut,

Le break est à éviter autant que possible : il est toujours possible de remplacer un break par une condition d'arret dans la boucle.
A partir de la, le break, c'est du "sucre syntaxique" venant du C++(je ne sais pas si celà existait avant mais en C++ ça existait) et visant à ne pas dépayser les programmeurs habitués à l'utiliser.

Comme disait un de mes profs :

Le break, c'est dangereux

Et je suis plutôt d'accord, même si je suis pour les return qui arrettent les boucles

F.

[T`lash]

Il y a un cas (et ce mot est bien choisi) où le break est inévitable et pourtant le principe en est strictement le même...

[herve91]

Ta vision du break et du return est assez contradictoire
Si tu es pour les return pour sortir d'une boucle, tu n'as aucune raison d'être contre le break. D'autant plus que si pour une raison x tu ne peux pas utiliser de return (par exemple d'autres traitements sont à faire) en sortie de boucle, et si tu ne veux pas utiliser de break, alors on en revient au code 1 du premier post !

[T`lash]

Quelqu'un ici peut me donner un bon argument contre j'utilisation du break ou du return mis à part les "c'est pas bien parce que mon prof me l'a appris" ?

Le "ça rend le code illisible" non plus ne sera pas accepté puisque si on c'est bien coder ça a l'effet inverse.

[mavina]

Ta vision du break et du return est assez contradictoire
Si tu es pour les return pour sortir d'une boucle, tu n'as aucune raison d'être contre le break. D'autant plus que si pour une raison x tu ne peux pas utiliser de return (par exemple d'autres traitements sont à faire) en sortie de boucle, et si tu ne veux pas utiliser de break, alors on en revient au code 1 du premier post !

Tu utilise une condition d'arret supplémentaire dans ta boucle.

Faire

Code :

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

1
2
3
4
while(maCondition1 && maCondition2){
//...
}
//traitement apres la bouche

ou faire

Code :

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

1
2
3
4
5
6
while(maCondition1){
//...
   if(maCondition2)
      break;
}
//traitement apres la boucle

C'est pareil.

Il y a un cas (et ce mot est bien choisi) où le break est inévitable et pourtant le principe en est strictement le même...

Cite le, on est là pour apprendre... Tu ne fais pas avancer le débat en disant qu'il y en a un sans le citer.

F.

[OButterlin]

il y a un cas où le break rendra le code beaucoup plus lisible :
- les boucles imbriquées

Code :

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

1
2
3
4
5
6
7
8
9
 
while (condition1)
{
   while (condition2)
   {
      // et là, je voudrais sortir de mes 2 boucles : vive le break !
   }
}
suite du code...

[mavina]

Mais en aucun cas il est indispensable.

Quand je peux l'éviter, je l'évite personnellement.

F.

[Napalm51]

Le fameux cas dont il parlait est le switch/case (d'où le choix du mot cas). Il est en effet difficile de faire sans, dans ce cas là