Discussion :

[voyager75]

Bonjour tous le monde,

Je recherche un plugin qui permet de sauvegarder les réductions (ouvertes ou fermées donc) lorsque je réouvre un .java.

J'entend par réduction, le mécanisme qui donne la possibilité de "fermer" la totalité d'une classe par exemple, ou une méthode.
Cela se passe dans le bandeau vertical à gauche du code.

Merci

[Laurent.B]

Bonjour,

Je ne sais pas s'il existe des plugins qui permettent de sauvegarder l'état mais le terme c'est : folding

[voyager75]

Merci, cela m'a aidé à en trouver un.

Il ne sauvegarde pas mais permet, lors de l'ouverture d'une source d'ouvrir/fermer:
- Commentaire
- Commentaire d'entête
- Type internes
- Méthodes
- Importations

C'est déjà ça. Si vous connaissez mieux...

Il s’appelle tout simplement Folding de Coffee-Bytes, accessible ici.

[Laurent.B]

Par défaut Eclipse gère le folding mais ne conserve pas non plus l'état, donc je ne sais pas ce que ton plugin a de plus mais à mon avis ce n'est pas grand chose...

Personnellement je n'ai jamais compris l'utilité de ce genre de fonctionnalité. Peut-être ne sais-je pas l'utiliser à bon escient mais bon, il y a la vue Outline qui permet d'avoir la vue d'ensemble et qui est paramétrable.
Bon, plus on a un grand écran, moi on a besoin de ce genre de fonction .

[voyager75]

Comme tu dis, Eclipse gère le folding, en fait ceux que j'ai indiqué plus haut sont ceux gérés par Eclipse.
Le plugin en question en gère 13, avec la possibilité d'en définir d'autres.

Lorsque j'ai la tête dans une classe depuis quelques jours, aucun intérêt de surcharger l'écran avec les constructeurs ou get/setters par exemple.
Même si je bosse sur portable 17" et écran 23".

Pour ce qui est de la outline view, je n'ai pas d'avis, je n'utilise pas. Je vais regarder.

[Laurent.B]

En fait, moi je me vois mal devoir ouvrir/fermer un bloc à chaque fois.

D'autre part, il faut aussi faire en sorte que tes classes soient bien architecturées. C'est peut-être déjà ton cas mais dans le cas contraire ça pourra être utile d'adopter ce genre de principes :

• Avoir des méthodes dont le contenu est inférieur à une page. Concrètement quelques dizaines de lignes mais l'important est surtout de rendre les algorithmes simples et donc facilement lisibles. Dès qu'on sent que ça devient difficile à suivre, on redécoupe en délégant certaines parties à des méthodes private. Eclipse permet ce type de refactoring de manière très pratique (CTRL + SHIFT + M) donc il ne faut pas hésiter.
• Une classe de type POJO (avec getters/setters) ne doit en principe pas contenir d'algorithme complexe, donc une fois qu'elle est définie, logiquement on ne s'intéresse qu'à ses attributs et la lecture est immédiate (si ceux-ci sont bien en début de classe). Donc avoir du folding là-dessus n'apporte rien.
• On doit également éviter de coder des classes qui prennent en charge tout et n'importe quoi. Dès qu'on sent qu'il y a matière à déléguer une partie, on redécoupe en créant une classe gérant celle-ci. Eclipse facilite également ce genre de refactoring.

A mon sens, ces principes permettent d'éviter le folding qui reste lourd à manipuler, même avec les raccourcis clavier. Et d'ailleurs, il y a aussi des raccourcis qui permettent de naviguer de méthode en méthode.

Si jamais tu as déjà une architecture correcte et que le folding te facilite malgré tout la vie, alors ne t'en prives pas

Sur du code XML, je ne dis pas que le folding n'a pas d'intérêt, c'est tellement verbeux que ça m'arrive de l'utiliser.