Code line wrapping - how to handle long lines

164,111

Solution 1

In general, I break lines before operators, and indent the subsequent lines:

Map<long parameterization> longMap
    = new HashMap<ditto>();

String longString = "some long text"
                  + " some more long text";

To me, the leading operator clearly conveys that "this line was continued from something else, it doesn't stand on its own." Other people, of course, have different preferences.

Solution 2

This is how I do it, and Google does it my way.

  • Break before the symbol for non-assignment operators.
  • Break after the symbol for = and for ,.

In your case, since you're using 120 characters, you can break it after the assignment operator resulting in

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

In Java, and for this particular case, I would give two tabs (or eight spaces) after the break, depending on whether tabs or spaces are used for indentation.

This is of course a personal preference and if your project has its own convention for line-wrapping then that is what you should follow whether you like it or not.

Solution 3

IMHO this is the best way to write your line :

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

This way the increased indentation without any braces can help you to see that the code was just splited because the line was too long. And instead of 4 spaces, 8 will make it clearer.

Solution 4

Uses Guava's static factory methods for Maps and is only 105 characters long.

private static final Map<Class<? extends Persistent>, PersistentHelper> class2helper = Maps.newHashMap();

Solution 5

I think that moving last operator to the beginning of the next line is a good practice. That way you know right away the purpose of the second line, even it doesn't start with an operator. I also recommend 2 indentation spaces (2 tabs) for a previously broken tab, to differ it from the normal indentation. That is immediately visible as continuing previous line. Therefore I suggest this:

private static final Map<Class<? extends Persistent>, PersistentHelper> class2helper 
            = new HashMap<Class<? extends Persistent>, PersistentHelper>();
Share:
164,111
corsiKa
Author by

corsiKa

I'm here to find out about the mysteries of air.

Updated on July 09, 2022

Comments

  • corsiKa
    corsiKa almost 2 years

    I'm facing a particular line that is 153 characters long. Now, I tend to break things after 120 characters (of course, this is heavily dependent on where I am and the local conventions.) But to be honest, everywhere I break the line just makes it look bad. So I'm looking for some ideas on what I should do for it.

    Here's the line:

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

    I'm open to both ideas about how/where to break the line (and why), as well as ways to shorten the line itself.

    We're not a Java shop, and there aren't local conventions for this sort of thing, or obviously I would simply follow them.

    Thanks!

  • helpermethod
    helpermethod over 13 years
    +1 Very good idea. If you don't want the additional dependency, it is very easy to write such a static factory on your own.
  • Carlos
    Carlos over 13 years
    I don't think using a library to get shorter lines is a good idea.
  • Anon
    Anon over 13 years
    And as a related comment: wouldn't it be nice if Java had typedef?
  • corsiKa
    corsiKa over 13 years
    Yes, yes it would. I'd even settle for &macros
  • whiskeysierra
    whiskeysierra over 13 years
    I would not recommend including it for that purpose, but many projects already use it. And as Helper Method pointed out, it's a one liner which saves some key strokes.
  • corsiKa
    corsiKa over 13 years
    An interesting idea, obviously that method was introduced for exactly this problem.
  • Colin Hebert
    Colin Hebert over 13 years
    I agree with the break before operators except with the assignment operator, I find it harder to read when your = is on the second line. And soon Java will have the Diamond operator :)
  • corsiKa
    corsiKa over 13 years
    I guess when I consider the two, I prefer it before even for =. I suppose that's just a matter of taste, but when I look at it, it makes the most sense.
  • C0M37
    C0M37 about 11 years
    You shouldn't use Google Guava Libraries just for the static factory methods. You should be using Guava because it will genuinely contribute to your java code quality in tons of other aspects. (Not to mention that it's wicked bullet proof due to the amount of time Google has spent on it...)
  • Hermes
    Hermes almost 11 years
    A line can start with an operator but should never end with it, in this case =. Check auto-formatting in your IDE. NetBeans would change this code for sure (tested).
  • Colin Hebert
    Colin Hebert almost 11 years
    The defaults settings of an IDE aren't relevant to personal preferences or the recommendations of a developer. I understand that some people would prefer to use the = at the beginning of the line, but in the case of the declaration of class attributes (or attributes in general for that matter) I consider that the code is already clear enough (the indentation of the second line should make it even more clear).
  • Colin Hebert
    Colin Hebert almost 11 years
    Just to be clear, there is no right and wrong here, it's purely aesthetics and personal opinions.
  • Hermes
    Hermes over 8 years
    I would prefer to follow the same rule for all operators if possible, and when you think of operators like +, - and so on, it is obviously more readable to break a line before them - just as if you were summing up values on a piece of paper. I believe that is the reason why this approach is commonly used. I mentioned NetBeans IDE as an example, not as an oracle (the pun was not intended). I agree that everyone may have their own preference, yet it is commonsensical that one should be preferred, and I believe this is why we are talking about it to begin with.