Discussion :

[Invité]

J'ai vu qu'on pouvait déclarer dans le code des accolades { } sans avoir à employer de mot clé java (comme "if").
Est ce que ça peut être utile ? (c'est vraiment une question ouverte)

Je sais que ça permet de limiter la visibilité des variables ou références déclarées dedans...
Est ce que ça peut déboucher sur des optimisations (comme une libération mémoire "forcée/explicite") ?

Merci

[herve91]

franchement, je ne l'utilise jamais, question relecture du code, c'est lourd, ça ajoute un niveau d'imbrication. Le seul intérêt que cela puisse avoir c'est effectivement de limiter la portée des variables et donc de rendre les objets locaux éligibles au GC plus rapidement. Mais si tel est le cas, à mon avis il est préférable d'extraire le code dans une méthode, c'est plus lisible. Et si ce n'est vraiment pas possible (par exemple parce qu'il faudrait passer trop de paramètres à la méthode en question), il est toujours possible de mettre la référence à null si elle n'est plus utilisée par la suite (si c'est juste un Integer, ce n'est peut-être pas la peine !).

[Uther]

Une autre utilisation possible des blocs est de les nommer pour utiliser le break dessus, ca permet de ce rapprocher du fonctionnement d'un goto.
Exemple:

Code :

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

1
2
3
4
5
6
bloc:{
  //...
  if (condition) break bloc;
  //...
}
//...

Mais autant dire que je ne vois pas vraiment de cas d'utilisation ou ce genre de chose soit vraiment utile. Par contre il est certain que la plupart des gens vont pousser (a tord ou a raison) des hurlements en voyant ce genre de code.

[professeur shadoko]

moi, au contraire, j'utilise pour rendre le code plus lisible.
exemples:
- dans une disposition graphique j'ai un panel intermédiaire de disposition ... alors toutes les dispositions qui le concerne sont dans un bloc à part (et non, une méthode ne s'impose pas pour diverses raisons)

Code :

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

1
2
3
4
5
6
7
8
 
      Panel intermédiaire = new Panel(new BorderLayout()) ;
      {
              intermediaire.add(labelInvite, NORTH) ;
              intermediaire.add(saisie, CENTER) ;
              /// etc...
      }
      this.add(intermédiaire, NORTH) ;

(note: j'évite de faire une classe anonyme avec le même code)

- j'ai une exception "traversante" : un appel de méthode risque de repropager l'exception et donc le code après cette méthode ne sera pas exécuté si il y a exception. je le marque donc de manière très lisible.

Code :

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

1
2
3
4
5
6
7
8
 
public void uneMéthode() throws UneMechanteException {
      // code
      objet.méthodeSusceptibleDeDéclencherException() ;
      NON_EXECUTE_EN_CAS_EXCEPTION : {
             // codes
      }
}

Au moment des spécifications des annotations j'avais proposé que de tels blocs puissent être annotés (ça permettrait de faire des choses astucieuses avec des outils de reingenierie du code)? ça n'a pas été retenu pour des raisons techniques (il me semble que le binaire ne connait pas ces blocs) mais, c'est promis, ça le sera un jour.

[professeur shadoko]

Mais autant dire que je ne vois pas vraiment de cas d'utilisation ou ce genre de chose soit vraiment utile. Par contre il est certain que la plupart des gens vont pousser (a tord ou a raison) des hurlements en voyant ce genre de code.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
EVERYTHING: {
    // code
    while(something) {
          // code
          if(çaVaPasDuTout) { break EVERYTHING ; }
          // autres codes
     }
     // code exécuté en cas de sortie "normale" du while
}
// code

Bien entendu on pourrait réécrire ça mieux avec des booléens appropriés et Niklaus Wirth n'aura pas à se retourner dans sa retraite.

[Uther]

Code :

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

1
2
3
4
5
6
7
8
9
10
EVERYTHING: {
    // code
    while(something) {
          // code
          if(çaVaPasDuTout) { break EVERYTHING ; }
          // autres codes
     }
     // code exécuté en cas de sortie "normale" du while
}
// code

Bien entendu on pourrait réécrire ça mieux avec des booléens appropriés et Niklaus Wirth n'aura pas à se retourner dans sa retraite.

Dans ce cas la il y a plus adapté:

Code :

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

1
2
3
4
5
6
7
8
EVERYTHING: while(something) {
          // code
          if(çaVaPasDuTout) { break EVERYTHING ; }
          // autres codes
     }
     // code exécuté en cas de sortie "normale" du while
}
// code

moi, au contraire, j'utilise pour rendre le code plus lisible.

C'était mon cas aussi mais je me suis fais engueuler par mes collègues. C'est tout simplement pas dans les habitudes de voir ça utilisé et la plus part des gens paniquent a tord en voyant ça.

[professeur shadoko]

Dans ce cas la il y a plus adapté:

Code :

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

1
2
3
4
5
6
7
8
EVERYTHING: while(something) {
          // code
          if(çaVaPasDuTout) { break EVERYTHING ; }
          // autres codes
     }
     // code exécuté en cas de sortie "normale" du while
}
// code

non, non regardes bien les deux codes ne font pas la même chose: il y a un code qui ne doit pas être éxécuté et qui l'est si tu étiquette le while au lieu d'étiqueter un bloc englobant.

[herve91]

non, non regardes bien les deux codes ne font pas la même chose: il y a un code qui ne doit pas être éxécuté et qui l'est si tu étiquette le while au lieu d'étiqueter un bloc englobant.

C'est là qu'on voit que c'est hyper dangereux !

[professeur shadoko]

C'est là qu'on voit que c'est hyper dangereux !

oui et non: au niveau algorithmique on risque l'excommunication .... au niveau lisibilité ça se lit très bien (comme toujours: quand on a l'habitude et une fois qu'on indente correctement)

[hibour]

une utilisation utile des {} est dans un case d'un switch, on peut limiter la variable déclaré dans un bloc case

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
switch (key) {
		case 1: {
			int a = 1;
			//...
			break;
                      }
		case 2: {
                        int a = 2;
			//....
			break;
		}
		//autres case
 
	}

Est ce une optimisation, j'en sais rien

[Invité]

une utilisation utile des {} est dans un case d'un switch, on peut limiter la variable déclaré dans un bloc case

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
switch (key) {
        case 1: {
            int a = 1;
            //...
            break;
                      }
        case 2: {
                        int a = 2;
            //....
            break;
        }
        //autres case
 
    }

Est ce une optimisation, j'en sais rien

Dans ton cas, le break ne va-t-il pas uniquement sortir de ton "case" (et non du "switch") ?

Par ailleurs, j'ai toujours trouvé la syntaxe du switch/case/break désuète ....
Des "case" indépendant les uns des autres (donc pas de "break") avec des délimitations par accolades seraient beaucoup plus logiques

[Uther]

non, non regardes bien les deux codes ne font pas la même chose: il y a un code qui ne doit pas être éxécuté et qui l'est si tu étiquette le while au lieu d'étiqueter un bloc englobant.

Oups en effet, j'ai regardé trop vite.

C'est là qu'on voit que c'est hyper dangereux !

C'est pas vraiment dangereux à moins d'en abuser.
Ça peux même rendre un code vraiment plus clair dans certains cas.

Dans ton cas, le break ne va-t-il pas uniquement sortir de ton "case" (et non du "switch") ?

Non le break simple ne sort que des bloc "for", "do", "while" et "switch".
Il ne sort pas des blocs "if" ou des blocs simples.

Le break avec un label, peut par contre sortir de n'importe quel type de bloc nommé.

Par ailleurs, j'ai toujours trouvé la syntaxe du switch/case/break désuète ....
Des "case" indépendant les uns des autres (donc pas de "break") avec des délimitations par accolades seraient beaucoup plus logiques

En effet, ca aurrait certainement été plus clair, mais ca permet tout de même de choses comme:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
switch(chiffre){
  case 0:
  case 2:
  case 4:
  case 6:
  case 8:
    return "pair";
  case 1:
  case 3:
  case 5:
  case 7:
  case 9:
    return "impair";
}

edit : corrigé suite a la remarque de Torg666

[Torg666]

Oups en effet, j'ai regardé trop vite.

C'est pas vraiment dangereux à moins d'en abuser.
Ça peux même rendre un code vraiment plus clair dans certains cas.

Non le break simple ne sort que des bloc "for", "do", "while" et "switch".
Il ne sort pas des blocs "if" ou des blocs simples.

Le break avec un label, peut par contre sortir de n'importe quel type de bloc nommé.

En effet, ca aurrait certainement été plus clair, mais ca permet tout de même de choses comme:

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
shitch(chiffre){
  case 0:
  case 2:
  case 4:
  case 6:
  case 8:
    return "pair";
    break;
  case 1:
  case 3:
  case 5:
  case 7:
  case 9:
    return "impair";
    break;
}

Le break après un return est une erreur il me semble.

[Uther]

En effet! C'est vrai que le break est inatteignable dans ce cas particulier car j'utilise return.

Ça fait parti des cas un java choisi bizarrement de retourner une erreur alors qu'un warning me parait tout indiqué.

[tchize_]

Exemple:

Code :

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

1
2
3
4
5
6
bloc:{
  //...
  if (condition) break bloc;
  //...
}
//...

Par contre il est certain que la plupart des gens vont pousser (a tord ou a raison) des hurlements en voyant ce genre de code.

HAAAAAAAAAAAAAAAAA!

block; ca prend un k en anglais, non mais, coder avec des noms français pour tes blocs, quelle idée, et pourquoi pas en japonais!

[Uther]

En fait je ne code pas en français mais en franglais, ce qui n'a rien a voir.

Tous les projets sur lequel je travaille depuis un moment sont en franglais intégral, la moité des développeurs utilisant des noms anglais, l'autre moité des noms français.
Du coup on finit par se retrouver avec des identifiants : StatutSubscription, ProfilFunctionality, ...

Mais là ou on comprend vraiment la puissance du franglais, c'est le moment où on se rend compte qu'il y a une propriété status et statut dans la même classe

[Invité]

moi je viens d'y trouver un intérêt pratique !
dans Eclipse, j'ai l'indentation automatique

là je bosse sur un projet en OpenGL
quand j'utilise des glPushMatrix() et glPopMatrix(),
c'est assez intéressant d'avoir le code entre ces 2 appels de fonction indenté
et c'est ce que font les accolades

[jabbounet]

HAAAAAAAAAAAAAAAAA!

block; ca prend un k en anglais, non mais, coder avec des noms français pour tes blocs, quelle idée, et pourquoi pas en japonais!

Tout dépend du contexte dans lequel tu travaille/developpe ton soft, j'ai vu des soft utilisant la langue de Molière pour nommer les fonction/variables/... qui était tout à fait maintenable pour un francophone.

concernant le japonais j'ai vu une offre d'emplois sur un site anglophone il n'ya pas si longtemps ou il cherchaient un développeur japanophone pour développer/maintenir un soft dans cette langue du coté d'osaka.....

l'important est de faire un choix au départ et de s'y tenir pour éviter les soucis dont parle uther avec l'attribut statut/status

bien sur si ton contexte est international et que ton code est partiellement ou totalement externalisé en inde il faut choisir l'anglais.

si tu développe ton soft pour une petite pme et que les personnes pour qui tu le fait ne parlent pas un mot d'anglais je ne suis pas certain que ce choix soit judicieux si tu désire qu'ils comprennent ce que tu as fait.

[tchize_]

si ils sont pas anglophone, je suis pas sur qu'il comprennent tout court, vu que 90% des appel se font sur des api soit standard soit importées de librairies externes, ils sont de facto en anglais. Programmer sans comprendre l'anglais c'est partir avec un sérieux handicap (pas d'accès aux docs officielles, pas d'accès aux apis importées, handicap important par rapport à la recherche de librairies faisant déjà le boulot, pas d'accès aux mailing listes officielles en cas de problème, etc)

Et puis tu sais jamais ou il va finir ton code. Tu commence pour une PME puis elle revend le code à une autre et c'est comme ça qu'au boulot on se coltine un code Fortran dont toutes les variables et tous les commentaires sont en polonais :s

[Uther]

Codez de manière sale et incompréhensible pour les autres, on ne pourra plus se passer de vous pour maintenir le programme.

Ayant du travailler sur des programmes commentés en roumain, je ne peux que valider. Heureusement que les noms de variables étaient quand même en anglais.

Ceci est cependant moins vrai aujourd'hui, les clients ayant généralement des exigences sur la qualité et la lisibilité du code.