Accolades et optimisation

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

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 !).

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:

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.

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:

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:

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.

Citation:

Envoyé par Uther

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:

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.

Citation:
Envoyé par professeur shadoko
Code:

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:

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
Citation:

Envoyé par professeur shadoko

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.

Citation:
Envoyé par Uther
Dans ce cas la il y a plus adapté:
Code:

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.

Citation:

Envoyé par professeur shadoko

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 ! :mrgreen:

Citation:

Envoyé par herve91

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

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

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

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 :mrgreen:

Citation:
Envoyé par hibour
une utilisation utile des {} est dans un case d'un switch, on peut limiter la variable déclaré dans un bloc case
Code:

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 :mrgreen:
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

Citation:

Envoyé par professeur shadoko

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.

Citation:

Envoyé par herve91

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

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

Citation:

Envoyé par PierreD87

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é.

Citation:

Envoyé par PierreD87

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:

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

Citation:
Envoyé par Uther
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:

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. :ccool:

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é.

Citation:
Envoyé par Uther
Exemple:
Code:

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!

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 :aie:

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

Citation:

Envoyé par tchize_

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.

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

Citation:

Envoyé par Mon prof d'algo

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

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.

moi j'ai un autre principe

ne vous rendez JAMAIS indispensable! On vous refusera vos congé et vos promotions à d'autres postes seront refusées.

Citation:

Envoyé par 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)

C'est assez disjoint ça, je parle de la langue dans laquelle tu fais ton programme à toi pour ton client (fabriquant de bicyclette pour nuages dans la Drôme âgé de 42 ans), pas de la langues des librairies/framework que tu va utiliser pour faire ton application.

De plus j'ai commencé a faire de l'informatique (programmation) je devais être en CM1/CM2/6ème sur amstrad avec du basic, à l'époque tu trouvais des bouquins en français qui t'expliquais que pour faire une boucle tu utilisais la commande "for" pour un test conditionnel tu utilisait un "if", je n'avais jamais fait d'anglais et je comprenais tres bien ce que je faisait.

Citation:

Et puis tu sais jamais ou il va finir ton code.

parfois oui, parfois non. sa destination finale est toujours la poubelle, après une durée de vie plus ou moins longue (entre "one shot" et 20 ans ou plus).

Citation:

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

C'est rare de ne pas savoir ce que ton client va faire de ton soft. s'il a l'intention de le revendre tu le saura. j'ai personnellement toujours su la finalité des softs dans lesquels j'ai été impliqué.
à partir de là tu t'adapte.

Citation:

Envoyé par Uther

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

Dans ce cas la langue fait très souvent partie des exigences du client et tu n'as pas à te poser la question.

Citation:

Envoyé par Uther

Citation:

Envoyé par Son prof d'algo

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

d'expérience personne n'est indispensable, et surtout pas celui dont tu n'arrive pas a comprendre ce qu'il fait ou qui n'arrive pas a te l'expliquer clairement.

Citation:

Envoyé par tchize_

moi j'ai un autre principe

ne vous rendez JAMAIS indispensable!

je plussoie fortement!

d'autant que les gens indispensables sont les premiers à gicler quand ils le deviennent moins... (expérience vécue)

;)

Citation:

Envoyé par tchize_

ne vous rendez JAMAIS indispensable! On vous refusera vos congé et vos promotions à d'autres postes seront refusées.

il y a la manière de se rendre indispensable: systématiquement transmettre ses savoir-faires, "élever" des remplacants pour tout, susciter une dynamique de groupe, etc..
Là c'est l'irremplaçable "open source" suprème :lol: et surtout refusez les promotions : vous ne feriez plus de programmation et vous finiriez dans le dernier carré des "mâles alpha". J'ai bossé dans une grande organisation dans laquelle les seuls "survivants" des guerres picrocholines en entreprise étaient ce genre de profil. (reflexion d'un cabinet de recrutement: "comment se fait-il qu'à votre age vous ne soyiez pas passé manager?" ... devinez!)