Code de retour à la ligne - comment gérer les longues lignes

Je suis face à une ligne particulière qui est de 153 caractères. Maintenant, j'ai tendance à casser des choses après 120 caractères (bien sûr, cela dépend fortement de l'endroit où je suis et les conventions locales.) Mais pour être honnête, partout où je le saut de ligne il fait juste l'air mauvais. Donc, je suis à la recherche de quelques idées sur ce que je dois faire pour elle.

Voici la ligne:

private static final Map<Class<? extends Persistent>, PersistentHelper> class2helper = new HashMap<Class<? extends Persistent>, PersistentHelper>();

Je suis ouvert à la fois des idées sur comment/où le saut de ligne (et pourquoi), ainsi que les moyens de raccourcir la ligne elle-même.

Nous ne sommes pas un Java boutique, et il n'y a pas de conventions locales pour ce genre de chose, ou de toute évidence, je voudrais simplement les suivre.

Merci!

InformationsquelleAutor corsiKa | 2010-09-16

41

En général, j'ai des lignes de rupture avant opérateurs, et indenter les lignes suivantes:
```
Map<long parameterization> longMap
    = new HashMap<ditto>();

String longString = "some long text"
                  + " some more long text";
```
Pour moi, le premier opérateur indique clairement que "cette ligne a été poursuivie à partir de quelque chose d'autre, il ne veut pas se tenir debout sur ses propres." D'autres personnes, bien sûr, ont des préférences différentes.
- Et comme un commentaire: ne serait-il pas agréable si Java a typedef?
- Oui, oui, il le ferait. J'irais même jusqu'à s'installer pour &les macros
- Je suis d'accord avec la pause avant que les opérateurs sauf avec l'opérateur d'affectation, je trouve ça plus difficile à lire lorsque votre = est sur la deuxième ligne. Et bientôt Java aura le Diamant de l'opérateur 🙂
- Je suppose que quand je considère les deux, je préfère avant même de =. Je suppose que c'est juste une question de goût, mais quand je la regarde, elle fait le plus de sens.
InformationsquelleAutor Anon
12

C'est de cette façon que je le fais, et Google n'a, à ma façon.
- Pause avant le symbole de de non-cession opérateurs.
- Pause après le symbole de = et pour ,.
Dans votre cas, puisque vous êtes à l'aide de 120 caractères, vous pouvez le casser après l'opérateur d'affectation entraînant
```
private static final Map<Class<? extends Persistent>, PersistentHelper> class2helper =
        new HashMap<Class<? extends Persistent>, PersistentHelper>();
```
En Java, et pour ce cas particulier, je voudrais donner deux onglets (ou huit places) après la pause, selon que des tabulations ou des espaces sont utilisés pour l'indentation.

C'est bien sûr une question de préférence personnelle et si votre projet a sa propre convention pour l'habillage de ligne alors qu'est ce que vous devez suivre si vous l'aimez ou pas.

InformationsquelleAutor Daniel
6

À mon humble avis c'est la meilleure façon de rédiger votre ligne :
```
private static final Map<Class<? extends Persistent>, PersistentHelper> class2helper =
        new HashMap<Class<? extends Persistent>, PersistentHelper>();
```
De cette façon, l'augmentation de l'indentation, sans les accolades peuvent vous aider à voir que le code était juste découpé parce que la ligne était trop long. Et au lieu de 4 places, 8 va le rendre plus clair.
- Une ligne peut commencer avec un opérateur, mais ne doivent jamais à la fin avec lui, dans ce cas =. Vérifier auto-mise en forme de votre IDE. NetBeans s'modifier ce code pour sûr (testé).
- Les paramètres par défaut d'un IDE ne sont pas pertinentes pour les préférences personnelles ou les recommandations d'un développeur. Je comprends que certaines personnes préfèrent utiliser les = au début de la ligne, mais dans le cas de la déclaration des attributs de classe (ou attributs en général d'ailleurs) je considère que le code est déjà assez claire (le retrait de la deuxième ligne devrait le rendre encore plus clair).
- Juste pour être clair, il n'y a pas de bon et de mal ici, c'est purement esthétique et opinions personnelles.
- Je préfère suivre la même règle pour tous les opérateurs, si possible, et quand vous pensez à des opérateurs comme +, - et ainsi de suite, il est évidemment plus lisible pour briser une ligne devant eux, comme si vous étiez en additionnant les valeurs sur un morceau de papier. Je crois que c'est la raison pour laquelle cette approche est couramment utilisée. Je l'ai mentionné NetBeans IDE comme un exemple, non pas comme un oracle (le jeu de mots n'était pas prévu). Je suis d'accord que tout le monde peut avoir ses propres préférences, mais il est commonsensical que l'on doit être préféré, et je crois que c'est pourquoi nous en parlons pour commencer.
InformationsquelleAutor Colin Hebert
4

Utilise Goyave statique de l'usine de méthodes pour les Cartes et est à seulement 105 caractères.
```
private static final Map<Class<? extends Persistent>, PersistentHelper> class2helper = Maps.newHashMap();
```
- +1 Très bonne idée. Si vous ne voulez pas la supplémentaires de dépendance, il est très facile d'écrire un tel statique usine sur votre propre.
- Je ne pense pas qu'à l'aide d'une bibliothèque pour obtenir des lignes plus courtes est une bonne idée.
- Je recommande de ne pas l'inclure dans ce but, mais de nombreux projets déjà l'utiliser. Et comme l'aide de la Méthode de relevé, c'est une doublure qui permet de gagner de touches.
- Une idée intéressante, bien évidemment que la méthode a été introduite pour exactement ce problème.
- Vous ne devriez pas utiliser Google Goyave Bibliothèques juste pour le statique méthodes de fabrique. Vous devriez être en utilisant la Goyave, car il va réellement contribuer à votre code java de la qualité dans la des tonnes d'autres aspects. (Pour ne pas mentionner que c'est méchant de preuve de balle en raison de la quantité de temps Google a passé sur elle...)
- D'accord...
InformationsquelleAutor whiskeysierra
0

Je pense que le fait de déplacer le dernier opérateur au début de la ligne suivante est une bonne pratique. De cette façon, vous saurez tout de suite le but de la deuxième ligne, même s'il ne commence pas par un opérateur. Je recommande aussi 2 espaces d'indentation (2 onglets) pour un déjà brisé onglet, diffèrent de l'indentation normale. Qui est immédiatement visible en continuant la ligne précédente. C'est pourquoi je suggère ceci:
```
private static final Map<Class<? extends Persistent>, PersistentHelper> class2helper 
            = new HashMap<Class<? extends Persistent>, PersistentHelper>();
```
InformationsquelleAutor Sasa

Vous devez vous connecter pour publier un commentaire.