Discussion :

[iohack]

Point de vue personel :
Je pense que ce genre de méthode ( break, continue etc. ) n'est pas propre dans la mesure ou ça casse la logique d'un algorithme fait à la main, mais surtout sa lisibilité et sa compréhension.
Maintenant, toutes les entreprises recherchent les performances, et des fois ces instructions permettent de gagner en rapidité ( d'exécution ou d'écriture du code ). Alors dire que les sources java sont sales, je n'irais pas jusque là. Du moment ou l'utilisation du code compilé est à la fois sûr et performant, peut-importe la gueule du source.

[Kikito]

Pour continuer la discussion,
1) Pourquoi ne pourrait-on pas incorporé des break dans un algo fait main ?
2) Pour la lisibilité et la compréhension, si tu prends mes 2 bouts de code en haut de cette seconde page, trouves-tu le second plus lisible que le 1er ?
3) Pour les 'throw' qui fonctionnent de la même manière, vous les sortez aussi des boucles avec des booléens pour ensuite lancer l'exception ?

[marchand_de_sable]

Petite question bête : comment s'utilise le continue ?? Il n'apparaît dans aucun de vos exemples...

Sinon, personnellement, je n'ai rien contre les break. Je ne les utilise que très rarement, mais c'est simplement parce que je n'y pense pas.
Mais du coup, il est vrai que je ne rends pas contre du coup de la maintenance de code contenant des break.

1) Pourquoi ne pourrait-on pas incorporé des break dans un algo fait main ?

Tout à fait d'accord. Je dirais même qu'il m'est arrivé de me prendre la tête sur une condition d'arrêt dans une boucle rédigée de manière "conventionnelle" (sans penser à utiliser un break). Il me semble que parfois les break collent mieux à la conception "humaine" d'une boucle. Les conditons d'arrêt peuvent être définies DANS le corps de la boucle, plutôt que dans la définition même de la boucle.
Je suis d'accord sur le fait qu'avec un algo bien conçu, les conditions d'arrêt des boucles ne devraient pas poser de problèmes lors de l'écriture du code. Dans la pratique, le break peut simplifier le travail...pourquoi s'en priver ?

[Kikito]

Petite question bête : comment s'utilise le continue ?? Il n'apparaît dans aucun de vos exemples...

De la même manière que les break sauf que cela passe à l'itération suivante au lieu de quitter définitivement la boucle.

Code :

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

1
2
3
4
5
6
7
for (int i=0;i<tableau.length;i++){
    //on ne gère que les éléments différents de 0.
    if (tableau[i] == 0){
        continue;
    }
    traitement(tableau[i]);
}

[marchand_de_sable]

De la même manière que les break sauf que cela passe à l'itération suivante au lieu de quitter définitivement la boucle.

OK, merci.
Je ne connaissais pas...

[pseudocode]

Perso, je vois pas d'autres manieres pour gerer les boucles infinies.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
while(true) {
 
  Integer i = getNextInteger();
 
  // ignore la valeur null
  if (i==null) continue;
 
  // sort si negatif
  if (i.intValue()<0) break;
 
  // traitement des entiers positifs ou nuls
  ...
}

[Kikito]

Perso, je vois pas d'autres manieres pour gerer les boucles infinies.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
while(true) {
 
  Integer i = getNextInteger();
 
  // ignore la valeur null
  if (i==null) continue;
 
  // sort si negatif
  if (i.intValue()<0) break;
 
  // traitement des entiers positifs ou nuls
  ...
}

Bien que j'utilise moi même les breaks/continues tu pourrais faire un truc 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
14
15
boolean end = false;
while(!end) {
  Integer i = getNextInteger();
  // ignore la valeur null
  if (i != null){
    // sort si negatif
    if (i.intValue()<0){
      end = true;
    }
    else{
      // traitement des entiers positifs ou nuls
       ...
    }
  }
}

[pseudocode]

Heu, oui mais bon, heu.., pour avoir un peu plus de lisibilité dans le code je suis adepte des techniques suivantes:

- le retour au plus tot
- l'indentation minimum

alors bon je vais garder ma technique, si ca ne derange personne

[Kikito]

Heu, oui mais bon, heu.., pour avoir un peu plus de lisibilité dans le code je suis adepte des techniques suivantes:

- le retour au plus tot
- l'indentation minimum

alors bon je vais garder ma technique, si ca ne derange personne

Je ne disais pas qu'il fallait faire comme la seconde solution, mais qu'on pouvait, car je suis d'accord avec toi, même si tout est biensûr important (il est important de connaitre les complexités des collections...) je privilégie également énormément la lisibilité/maintenance, car ce qui compte je pense dans les applis java pros c'est le travail d'équipe, la productivité et la maintenance beaucoup plus plus que le gain de performance de 2.4% ou les précepts old school disant que les instanceof, les return hors fin de fonction, les continue ou les breaks ne sont pas à utiliser.

[pseudocode]

Totalement d'accord.

Donc on peut conclure par:

Utilisez les break et les continue si cela ameliore la lisibilité du code. Sinon, laissez tomber.

[professeur shadoko]

qui disait "appuyez vous sur vos principes!... ils finiront bien par céder!"?
on peut toujours exhiber des utilisation algorithmiques vraiment pas propres de break .... mais on peut aussi en exhiber des correctes quand dans le corps de la boucle on calcule un résultat qui, pour un raison ou une autre, est inaccessible au test haut (ou au test bas dans le cas d'un do ...while()). On pourrait certes rajouter des tas de booléens invraisemblables mais là on rend le code hyper pas clair.
On peut avoir des codes tout à fait correct algorithmiquement avec des breaks (l'analyse physique du cheminement des branches du code est juste plus compliquée).... si on pousse trop loin nos besoins (légitimes) de pureté je signale que l'affectation est aussi considérée comme nuisible à la santé algorithmique

[pseudocode]

si on pousse trop loin nos besoins (légitimes) de pureté je signale que l'affectation est aussi considérée comme nuisible à la santé algorithmique

Supprimons les algos. Toutes les valeurs en dur, avec duplication du code et un gros switch/case.

[professeur shadoko]

Supprimons les algos. Toutes les valeurs en dur, avec duplication du code et un gros switch/case.

tu rigoles : mais j'ai vu du code Java généré automatiquement à partir de "vieux" langages de gestion et c'était exactement ça! terrifiant! tu prends une usine à gaz et tu remplaces chaque tuyau par un switch!

[chtig]

En ce qui me concerne, les break et autres continue c'est vraiment en dernier recours.
La lisibilité, ce n'est pas une mesure absolue. Mais en ce qui me concerne, quand j'ai une boucle, le reflexe est réellement de voir où elle démarre ou elle s'arrête et comment on évolue dedans. Une fois que c'est fait, je suis alors dans la boucle et le fait que la boucle existe n'a plus aucune influence sur ma compréhension.
Quand on utilise des break et des continue (enfin surtout des break), on ne peut absolument pas réfléchir de la même manière, en considérant qu'on est simplement en train de traiter un cas et oublier la boucle environnante (et si on parle de boucles imbriquées c'est encore pire).

Donc d'accord avec le phrase "break et continue quand ça améliore la lisibilité" mais à mon sens ça n'arrive que rarement.

[professeur shadoko]

Donc d'accord avec le phrase "break et continue quand ça améliore la lisibilité" mais à mon sens ça n'arrive que rarement.

voyons avec un exemple (sans try/catch pour simplifier)

Code :

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

1
2
3
4
5
6
 
for(int ix = 0; ix < tb.length; ix++) {
     int lu = System.in.read() ;
      if( (lu == -1) || (lu == '\n') || (lu == '\r')) { break ;}
     tb[ix] = lu ;
}

objet: réécrire ce code (pas très pertinent je le concède) sans break et sans variable interne à la boucle déclarée à l'extérieur de la boucle.
C'est possible certes...
après du goût et des couleurs on peut discuter....

[yann2]

Bonjour

Je préfère ça :

Code :

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

1
2
3
4
5
6
7
8
 
for(int ix = 0, int lu = System.in.read() ; ix < tb.length && !lectureTerminee(lu) ; ix++, lu = System.in.read()) {
     tb[ix] = lu ;
}
 
private static boolean lectureTerminee(int lu) {
     return (lu == -1) || (lu == '\n') || (lu == '\r');
}

Et je préfère encore ça (mais apparement tu ne le veux pas) :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
int lu = System.in.read();
for(int ix = 0; ix < tb.length && !lectureTerminee(lu) ; ix++) {
   tb[ix] = lu ;
   lu = System.in.read();
}
 
private static boolean lectureTermine(int lu) {
     return (lu == -1) || (lu == '\n') || (lu == '\r');
}

J'aurai même préféré un while en fait.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
int indiceCourant = 0;
int lu = System.in.read();
while (!lectureTerminee(lu) && indiceCourant < tb.length) {
    tb[indiceCourant] = lu;
    indiceCourant++;
    lu = System.in.read;
}
 
private static boolean lectureTerminee(int lu) {
     return (lu == -1) || (lu == '\n') || (lu == '\r');
}

[chtig]

J'ai du mal avec ta notion de "variable interne à la boucle" ....
En quoi tu considères que ta variable lu ne peut pas être déclarée à l'extérieur ?

Effectivement, la lisibilité c'est très subjectif. Si ça se compte en nombre de lignes et nombre d'indentations, que penses tu de ça ? :

Code :

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

1
2
3
 
for (int ix=0;ix < tb.length && (int lu=System.in.read())!=-1 && lu!='\n' && lu!='\r'; ix++)
     tb[ix] = lu ;

[pseudocode]

Effectivement, la lisibilité c'est très subjectif. Si ça se compte en nombre de lignes et nombre d'indentations, que penses tu de ça ? :

Ce qui est moins "subjectif" ce sont les metriques, comme par exemple la "cyclomatic complexity Number (CCN)" de McCabe:

CCN is also know as McCabe Metric. There exists a much hyped theory behind it based on graph theory, but it all comes down to simply counting 'if', 'for', 'while' statements etc. in a method. Whenever the control flow of a method splits, the "CCN counter" gets incremented by one.

Each method has a minimum value of 1 per default.

For each of the following keywords/statements this value gets incremented by one:

• if
• for
• while
• case
• catch
• &&
• ||
• ?

Note that else, default, and finally don't increment the CCN value any further. On the other hand, a simple method with a switch statement and a huge block of case statements can have a surprisingly high CCN value (still it has the same value when converting a switch block to an equivalent sequence of if statements).

[chtig]

Oui effectivement il existe des métriques, mais comme le signale l'auteur lui même, elles ont de très nettes limitations, et il est rare de pouvoir réellement en tirer une appréciation réelle de la lisibilité du code.

[pseudocode]

C'est clair. a chacun de definir ce qu'il appelle "lisibilité".

Exemple avec le celebre STRCOPY

Code :

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

1
2
3
4
5
6
7
8
 
strcpy(char s1[],char s2[])
{
    int x,len;
    len=strlen(s2);
    for (x=0; x<=len; x++)
        s1[x]=s2[x];
}

Code :

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

1
2
3
4
5
6
7
8
9
10
 
strcpy(char *s1,char *s2)
{
    while (*s2 != '\0')
    {
        *s1 = *s2;
        s1++;
        s2++;
    }
}

Code :

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

1
2
3
4
5
6
 
strcpy(char *s1,char *s2)
{
    while (*s2)
        *s1++ = *s2++;
}

Code :

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

1
2
3
4
5
 
strcpy(char *s1,char *s2)
{
    while (*s1++ = *s2++);
}