Discussion :

[Arnaoud]

Bonjour,

Le break est bien pratique pour sortir d'une boucle mais parait un peu trop facile. En particulier dans le cas.

Code :

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

1
2
3
4
5
6
7
 
for(int i=0; i<tab.length(),i++){
  if (tab[i] == 4){
     bfind=true;
     break;
  }
}

Pouvez vous me dire si l'utilisation d'un break au sein d'une boucle for ou while est une bonne pratique? Le fait d'utiliser break a t il des conséquences négatives sur l'execution du programme (par exemple au niveau des optimisation des performances, ...) , ou si cela reviens au même de programmer sans les break?

Je n'arrive pas à trouver de réponse argumentée à ce sujet.

Merci par avance.

Arnaud.

[19cmos83]

Le déroulement de toutes les instructions d'itération peut être contrôlé de l'intérieur du corps de la boucle au moyen des instructions break et continue. L'instruction break sort de la boucle sans exécuter la suite des instructions. L'instruction continue arrête l'exécution de l'itération courante, et l'exécution reprend en début de boucle avec l'itération suivante.

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
16
17
18
19
20
21
//: c03:BreakAndContinue.java
// Démonstration des mots clefs break et continue.
 
public class BreakAndContinue {
  public static void main(String[] args) {
    for(int i = 0; i < 100; i++) {
      if(i == 74) break; // Sortie définitive de la boucle for
      if(i % 9 != 0) continue; // Continue avec l'itération suivante
      System.out.println(i);
    }
    int i = 0;
    // une "boucle infinie" :
    while(true) {
      i++;
      int j = i * 27;
      if(j == 1269) break; // Sortie de boucle
      if(i % 10 != 0) continue; // Début de boucle
      System.out.println(i);
    }
  }
} //

Dans la boucle for la valeur de i n'atteint jamais 100 car l'instruction break termine la boucle lorsque i prend la valeur 74. En principe, il ne faudrait pas utiliser break de cette manière, à moins que l'on ne connaisse pas le moment où la condition de fin arrivera. L'instruction continue provoque un branchement au début de la boucle d'itération (donc en incrémentant i) chaque fois que i n'est pas divisible par 9. Lorsqu'il l'est, la valeur est imprimée.

La seconde partie montre une « boucle infinie » qui, théoriquement, ne devrait jamais s'arrêter. Toutefois, elle contient une instruction break lui permettant de le faire. De plus, l'instruction continue retourne au début de la boucle au lieu d'exécuter la fin, ainsi la seconde boucle n'imprime que lorsque la valeur de i est divisible par 10.

http://www.google.fr/search?hl=fr&cl...a=lr%3Dlang_fr
1er lien.

@+


NB : Le principe d’optimisation consiste à ne pas continuer à tester lorsque le résultat est connu.

[Arnaoud]

Merci pour ta réponse,

Elle est très claire.

Existe t il de bonnes raisons de ne pas l'utiliser?

[OButterlin]

Existe t il de bonnes raisons de ne pas l'utiliser?

Je n'en vois pas, sauf peut-être l'envie de se faire braire avec des if

A+

[natha]

Je n'en vois pas, sauf peut-être l'envie de se faire braire avec des if

Vin de dious ! J'me s'rais attendu à lire des "les breaks et continue faut pas utiliser, c'est un résidu de goto beurk beurk" !

J'utilise de temps en temps, par pure flemme de réfléchir à l'instruction while ou dowhile qui irait bien pour sortir de la boucle sans utiliser break.

[OButterlin]

Vin de dious ! J'me s'rais attendu à lire des "les breaks et continue faut pas utiliser, c'est un résidu de goto beurk beurk" !

Pourquoi tu dis ça ? J'ai l'air d'un intégriste des langages de programmation ?

[Arnaoud]

les breaks et continue faut pas utiliser, c'est un résidu de goto beurk beurk

J'avais envie de répondre la même chose que toi. Mais pourquoi ??? Ca parait pratique quand même.

J'ai imaginé deux raisons:
- Pb d'optimisations au niveau de la compil
- Risque d'erreur si l'on rajoute un bloc dans le while, le break sortira du bloc mais pas du while.

C est assez maigre comme raison, Je ne vois rien de plus concret.

Merci de vos réponses

[19cmos83]

si ils y sont, c'est que c'est pas pour les chiens ! beuh !


NB :

Arnaoud :
il dit précédemment :

Vin de dious ! J'me s'rais attendu à lire des "les breaks et continue faut pas utiliser, c'est un résidu de goto beurk beurk" !

[natha]

Pourquoi tu dis ça ? J'ai l'air d'un intégriste des langages de programmation ?

Pas toi particulièrement, mais c'est ce que j'ai eu l'occasion de lire assez souvent.

Utilisé avec parcimonie là où ça améliore la lisibilité ça ne me dérange pas personnellement.

Il faut savoir qu'on a aussi la possibilité d'utiliser les labels, et là je suis plus réservé sur le bienfondé de leur utilisation.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
		TEST: for (int i = 0; i < 1000; i++) {
			if (i < 500) {
				continue TEST;
			}
			for (int j = 0; j < 1000; j++) {
				if (i + j == 1500) {
					break TEST;
				} else if (i > j) {
					continue;
				} else {
					continue TEST;
				}
			}
		}

Sûr que vous rigolez moins maintenant

[adiGuba]

Salut,

Utilisé avec parcimonie là où ça améliore la lisibilité ça ne me dérange pas personnellement.

+1 c'est comme tout il ne faut pas en abuser !

Cela peut rendre le code plus simple et plus lisible, tout comme cela peut générer un code affreux !


Mais perso j'aurais tendance à privilégier les break afin d'éviter d'avoir des conditions d'arrêt à rallonge...


a++

[Tommy31]

L'usage doit en être modéré de la même façon qu'un goto en C/C++ (oui ce n'est pas mal d'utiliser un goto dans des cas bien précis).

L'intérêt majeur d'un break, c'est que la continuation est connue: on s'échape de la boucle locale et on exécute les instructions qui la suivent. Maintenant quand on labélise les boucles imbriquées, ca devient bien plus chaud de s'y retrouver !

[Arnaoud]

Je vous remercie pour les réponses.

Je peux donc résumer le débat par:
On peut utiliser des breaks s'ils ne diminuent pas la lisibilité du code.
A part ces problèmes de lisibilité, Il n'y a pas d'autres raisons apparement de ne pas les utiliser.

Arnaud