Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

While Sun's Java code convention suggests to put line break before the operator many other guidelines disagree with it. I do not see any obvious pros and cons, so are there advantages of using one of these styles over another?

String longVarName = a + b + c + d +
          e + f;

vs

String longVarName = a + b + c + d
          + e + f;
share|improve this question

closed as primarily opinion-based by gnat, Florian Margaine, MichaelT, Martijn Pieters, Bart van Ingen Schenau Sep 2 at 9:33

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Can you please post a simple code example showing both conventions? –  Michael Jul 17 '11 at 14:06
    
First I would try to avoid the situation by using something like this: download.oracle.com/javase/1.4.2/docs/api/java/lang/… –  Job Jul 17 '11 at 15:13
    
The link is broken. –  Florian F Sep 1 at 15:42

9 Answers 9

up vote 5 down vote accepted

This could sound silly, but:

It's expression, leave everything on one line - and as soon as it will become messy start with refactoring:

  • renaming vars
  • introducing new vars/functions

Code formatting is important, however proper and meaningful architecture is much more powerful.

subtotal = price * (1+tax_ratio) / 100 vs. subtotal = price + tax

share|improve this answer
1  
The formula on the left is incorrect. It should be either price * (100 + tax_ratio) / 100 or just price * (1 + tax_ratio), depending on whether tax_ratio is in percent or fractional. –  Rufflewind Sep 1 at 17:40

I can imagine readability being an argument

result = longidentifier +
   short -
   alittlelonger -
   c;

versus

result = longidentifier
   + short
   - alittlelonger
   - c;

In the second example the operators are nicely lined up and you can easily see with which sign the variable enters into the equation. I think this also makes sense for binary operators, but with bracing etc., you should just do whatever is clearer.

share|improve this answer
3  
For situations where the operators are important (like math expressions and such) I would choose number two, because, as you said, it is much more readable. But for strings I would choose the first options, as the operators are "meaningless". They don't do anything other than bringing strings together, and because the strings are the important bit, then I would prefer the first options. –  Niklas H Jul 17 '11 at 14:50
    
Both cases have merit. Both cases are better than putting it all on one very long line! My preference is to to use an opening bracket at the start (even though its not needed) and then having everything line up under that. It makes it far more obvious. –  quickly_now Jul 18 '11 at 9:00

In code I tend to put the break after the operator:

foo = some_long_expression() +
      some_other_long_expression();

Here that dangling operator at the end of a line is a big clue to the reader that the code continues. In languages that don't have statement terminators, that dangling operator can serve as a sufficient clue to the compiler/interpreter that the code continues (otherwise I would have to use some ugly continuation line construct).

When documenting that expression (if it needs documentation), I tend to put the break before the operator.

share|improve this answer
    
At least some languages (e.g. Python) don't take a trailing binary operator as hint that the line continues but require more. Note that newlines inside parens usually aren't counted , so you don't need an explicit (and error-prone) line continuation character. –  delnan Jul 17 '11 at 15:22

As long as you remain consistent, then know there's no real advantage either way. This is especially important when considering code merges and white space.

share|improve this answer

For long arithmetic equations, I typically do one of two things.

leave everything on a single line:

foo = bar + baz - fizz + buzz + alpha - beta;

I typically do this for equations containing only addition and subtraction, i find it very easy to make a typo with multiplication and division that can seriously mess up the scope of the operator.

the second format I use is progressive operators:

foo = bar;
foo += baz;
foo -= fizz;
foo += buzz;
foo /= alpha - beta;
foo *= spiff;

I see no reason to shorten it to a single line, unless it can be proven to improve performance in a noticeable manner. Additionally, there's no ambiguity of what's going on where, and there's less of a chance to misplace a parenthesis for the / and * operators.

share|improve this answer

Placing the concatenation character (or any operator) at the beginning of the line improves readability. We scan code by focusing on the beginning of each line. When a line starts with an operator, the reader can tell that the line is a continuation of the previous statement by scanning that one character.

Long mathematical expressions are always typeset so that each new line begins with an operator. There is no reason that code should not follow this convention.

share|improve this answer

I believe the line should start with the highest symbol in the parse tree of the statement you want to break. It highlights the operator that is most important in the expression. It is the same reason why you put an else at the begin of a line and not at the end of the previous line.

In the following example, scanning the left margin, you see the structure of the statement as an OR of 3 expressions.

if (ch>='A' && ch<='Z'
    || ch>='a' && ch<='z'
    || ch>='0' && ch<='9')
{...}

Below, the || operators are less highlighted. It is less obvious it is an || of expressions. Especially if the lines were diffent lengths.

if (ch>='A' && ch<='Z' ||
    ch>='a' && ch<='z' ||
    ch>='0' && ch<='9')
{...}

And just for reference, this is very wrong. The || operators are not highlighted at all.

if ( ch>='A' && ch<='Z' || ch>='a'
     && ch<='z' || ch>='0' && ch<='9')
{...}

I even like to put commas at the beginning of the line, even though I seldom see that. I refrain from doing that on shared code.

var note:Object =
    { key: key
    , type: 'P'
    , text: someLongProcedureCallGettingTheUserInitials()
       + ": " + getTheTextThatWasTyped()
    };
share|improve this answer

I normally follow the most commonly used style guidelines or a certain coding standard tools. The advantage of using a commonly used style brings benefits when you are reading other people's code or involved in a open source project where a style guidelines are set.

The most common styles that I have seen is the second style in the question. See the below for the list of them:

Google Style Guide:

When a line is broken at a non-assignment operator the break comes before the symbol.

Sun Coding Convention:

Break before an operator

Checkstyle Operator Wrap check's default value is nl:

The operator must be on a new line

share|improve this answer
    
this doesn't even attempt to answer the question asked, "are there advantages of using one of these styles over another?" –  gnat Sep 1 at 14:43
    
Updated my answer for clarity sake + Sun's coding convention. –  ceilfors Sep 1 at 16:08

Leave the expression on one line, and if it becomes too long, then break it up into smaller expressions:

days = ((year * months_per_year) + month) * days_per_month + day

becomes:

months = year * months_per_year + month
days = months * days_per_month + day

If this isn't possible, then I find it more readable to break before the operator, and have the operator begin directly below the previous assignment (putting it below the variable makes me have to think and recenter, which is annoying given that the goal is to make things easier to read):

random = years * months_per_year 
         + month * days_per_month 
         + day * hours_per_day 
         + hour * minutes_per_hour 
         + minute * seconds_per_minute 
         + second
share|improve this answer
1  
This answer doesn't add anything new to what has already been said. –  Martijn Pieters Sep 2 at 7:58

protected by MichaelT Sep 2 at 3:01

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.