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.

[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