Discussion :

[mlny84]

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.

Il est peut être fait allusion au cas du switch :

Code :

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

1
2
3
4
5
6
switch(var){
case '1' : {... ; break;}
case '2' : {... ; break;}
...
}

Là je pense que le break est plus que indispensable.

Edit : grillée

[herve91]

Code :

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

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

ou

Code :

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

1
2
3
4
5
6
7
8
9
		PosteBudgétaire posteBudgétaire = null;
		boolean trouvé = false;
		Iterator ite = postes.iterator();
		while(ite.hasNext() && !trouvé){
			posteBudgétaire = (PosteBudgétaire) ite.next();
			if( posteBudgétaire.getLabel().compareToIgnoreCase(s)==0 ){
				trouvé = true;
			}
		}

On en revient au premier message... Quelle est l'écriture la plus lisible ?
En plus avec cette écriture on appelle une fois de trop hasNext(). Il faudrait plutôt écrire :

Code :

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

while(!trouvé && ite.hasNext()){

[mavina]

Ah mais on sort du contexte boucle là, vous êtes tous des fourbes

C'est sur, ce break là fait partie de la sémantique du switch, ils sont indissociables ...

F.

[OButterlin]

Ah mais on sort du contexte boucle là, vous êtes tous des fourbes

c'est pas faux

Mais bon, franchement, je ne vois pas ce qui gêne avec le break...
ça me rappel les discussions à l'époque des goto dans tous les sens, mais c'était des programmes linéaires avec 300 lignes de code...
Là, effectivement, goto vers le bas et goto vers le haut, très vite, on ne sait plus où on est...

Dans tous les cas, c'est vouloir être plus royaliste que le roi, parce qu'en langage machine, il n'y a que ça à l'arrivée, non ?

[mavina]

Ah oui, mais si tu veux faire du langage machine ne fais pas de java

Quoi qu'il en soit, je préfère faire une condition d'arret en plus que de faire un break, et celà revient au même

Chacun ses tics de programation

F.

[T`lash]

Ah oui, mais si tu veux faire du langage machine ne fais pas de java

Quoi qu'il en soit, je préfère faire une condition d'arret en plus que de faire un break, et celà revient au même

Chacun ses tics de programation

F.

Ah... tu as enfin dit ce que je voulais que tu dises et qui réponds à la question du premier post : il s'agit de préférences de programmation.

Ceux qui sont allergiques aux return multiples et aux break
ne les utilisent pas et ceux qui trouvent que ça simplifie les choses et allège le code n'ont pas à s'en priver.


Donc, faites comme vous voulez tant que ça n'irrite pas trop vos collègues parce qu'ils ne sont pas du même avis, s'ils doivent travailler sur le même code que vous. Mais dans ce cas il y a une mauvaise répartition des tâches à la base.

[mavina]

Tant que c'est commenté...

Et non ca ne répond pas au premier post, ce qui répond au premier post, c'est "code numéro 2, car le code numéro 1 continue d'itérer et ce malgré le fait qu'il ai trouvé ce qu'il doit retourner", mais je chipote bien sûr

F.

[Uther]

Pour moi le break tout comme continue et return sont des instructions bien utile qu'il ne faut surtout pas avoir peur d'utiliser. Je trouve que contrairement à ce que certains disent ils rendent les programmes bien plus lisibles.

break ne doit pas être employé en début ou fin de boucle while bien évidement.
Par contre rajouter un booléen pour eviter un break comme dans l'exemple donné n'est pas plus lisible à mon avis, et dans certain cas, ça peut devenir carrément moche.
En effet on continue l'execution inutile d'une boucle. Pour peu que la boucle effectue plusieurs opérations à la suite, toutes les opérations suivantes devraient soit être exécutées pour rien soit être placées dans un if

break et continue permettent d'éviter d'avoir trop de if imbriqués qui sont à mon avis une des principales cause de code pas clair.

je trouve que un code du genre:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
for(MonObjet obj : listeObjets){
    if (!obj.isValide() ) {
        System.out.println("Erreur: données invalides");
        break;
    }
    if (!obj.isTraitable() ) {
        System.out.println(obj+" non traité");
        continue;
    }
    obj.traitement();
    System.out.println(obj+" traité");
 
}

est autrement plus clair que

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
for(MonObjet obj : listeObjets){
    boolean valide = obj.isValide();    
    if (valide){
        boolean traitable = obj.isTraitable();
        if(traitable){
            obj.traitement();
            System.out.println(obj+" traité");
        } else {
            System.out.println(obj+" non traité");
        }
    }else{
        System.out.println("Erreur: données invalides");
    }
}

[Romain B.]

Pour moi le break tout comme continue et return sont des instructions bien utile qu'il ne faut surtout pas avoir peur d'utiliser. Je trouve que contrairement à ce que certains disent ils rendent les programmes bien plus lisibles.

break ne doit pas être employé en début ou fin de boucle while bien évidement.
Par contre rajouter un booléen pour eviter un break comme dans l'exemple donné n'est pas plus lisible à mon avis, et dans certain cas, ça peut devenir carrément moche.
En effet on continue l'execution inutile d'une boucle. Pour peu que la boucle effectue plusieurs opérations à la suite, toutes les opérations suivantes devraient soit être exécutées pour rien soit être placées dans un if

break et continue permettent d'éviter d'avoir trop de if imbriqués qui sont à mon avis une des principales cause de code pas clair.

je trouve que un code du genre:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
for(MonObjet obj : listeObjets){
    if (!obj.isValide() ) {
        System.out.println("Erreur: données invalides");
        break;
    }
    if (!obj.isTraitable() ) {
        System.out.println(obj+" non traité");
        continue;
    }
    obj.traitement();
    System.out.println(obj+" traité");
 
}

est autrement plus clair que

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
for(MonObjet obj : listeObjets){
    boolean valide = obj.isValide();    
    if (valide){
        boolean traitable = obj.isTraitable();
        if(traitable){
            obj.traitement();
            System.out.println(obj+" traité");
        } else {
            System.out.println(obj+" non traité");
        }
    }else{
        System.out.println("Erreur: données invalides");
    }
}

non !! je ne suis pas d'accord ; pour moi le second est plus lisible.
surtout si celui qui n'est pas familiarisé avec break et continu reprends ton code. L'avantage de ne pas utiliser ces instructions, c'est flagrant dans ton exemple, est que le code est bien divisé en blocs. Avec le continu, une suite d'instruction qui au premier coup d'œil devrait être n'exécute ne le sera en fait peut être pas...
je préfère imbriquer 2 if et avoir un code dont le fonctionnement "saute aux yeux" qu'utiliser ces raccourcis syntaxiques assez ambigus.

[Uther]

surtout si celui qui n'est pas familiarisé avec break et continu reprends ton code. L'avantage de ne pas utiliser ces instructions, c'est flagrant dans ton exemple, est que le code est bien divisé en blocs. Avec le continu, une suite d'instruction qui au premier coup d'œil devrait être n'exécute ne le sera en fait peut être pas...

Si tu ne connais pas break et continue, c'est que tu ne connait pas les bases même du langage. Ce genre de chose ne devrait surprendre personne.

je préfère imbriquer 2 if et avoir un code dont le fonctionnement "saute aux yeux" qu'utiliser ces raccourcis syntaxiques assez ambigus.

On a pas la même notion de saute au yeux alors. Avec des if, la détection et le taitement sont a l'opposé dans le code. Ici il n'y a que des instruction d'une ligne donc, ca reste assez lisible mais si tu fait plusieurs test qui tiennent sur plusieurs lignes les imbrications vont devenir très lourdes.

[T`lash]

Là dessus je suis d'accord car même si je le trouve bien pratique et que je l'utilise moi aussi, l'utilisation du continue rend forcément le code plus ambigüe contrairement au break.

Je ne dis pas qu'il est à proscrire, bien au contraire, mais chaque utilisation de ce mot réservé doit être commenté. Et comme le fait de devoir écrire un commentaire à chaque fois enlève l'argument de rapidité cela fera moins d'adeptes de la chose.
Par contre, théoriquement si c'est utilisé systématiquement à de nombreux endroits du code d'un programme c'est sensé en augmenter les performances puisque l'on utilise une instruction proche d'une instruction machine qui réduit le nombre de if.
Dans la plupart des programmes ce sera sans effet, mais dans certains cas ça peut être visible.

[Romain B.]

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
 
for(MonObjet obj : listeObjets){
    boolean valide = obj.isValide();    
    if (valide){
        boolean traitable = obj.isTraitable();
        if(traitable){
            obj.traitement();
            System.out.println(obj+" traité");
        } else {
            System.out.println(obj+" non traité");
        }
    }else{
        System.out.println("Erreur: données invalides");
    }
}

d'un coté, tu n'es pas très objectif, ce code peut être très lisible, sans utiliser break et continue :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
	for(MonObjet obj : listeObjets){
		if (!obj.isValide()){
			System.out.println("Erreur: données invalides");
		}
		else if(!obj.isTraitable()){
			System.out.println(obj+" non traité");
		} 
		else {
			obj.traitement();
			System.out.println(obj+" traité");
		}
	}

[T`lash]

C'est pour ça qu'il ne faut pas généraliser : au cas par cas il faut avoir le réflexe d'utiliser l'une ou l'autre des solutions.

Romain B. a bien montré que parfois il suffit d'une simple optimisation du code.

Par contre, le break est quant à lui très utile lorsque le nombre de boucles imbriquées devient vraiment trop important, mais ce n'est pas dans un exemple de quelques lignes que l'on en viendra à ce degré de complexité à moins de vraiment le faire exprès. Et dans ce dernier cas il y a toujours moyen de remanier les tests conditionnels afin de clarifier les choses.

[OButterlin]

Ça risque de virer au troll... je pense qu'il faudrait conclure...

Pour ma part, je dirais que la seule chose à proscrire c'est d'interdire ou de faire croire que c'est "mal".
Il ne s'agit pas non plus de "convertir", chacun ses habitudes, dans certains cas c'est mieux et plus lisible et il ne faut pas s'en priver.

Bye

[Uther]

d'un coté, tu n'es pas très objectif, ce code peut être très lisible, sans utiliser break et continue :

Oui c'est vrai que mon exemple n'est pas bon vu qu'ici on est pas obligé d'imbriquer les if les un dans les autre et que les test et traitements ce font en une ligne.
Ceci dir parfois, à refuser de faire break et continue, on ce retrouve avec des niveaux d'imbrications inutiles et quand les code commencent a ralonger, ca peut être moche.