Line break before or after binary operator? [closed]

Question

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. Are there advantages of using one of these styles over the other?

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

vs

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

Answer 1

I'd leave it on one line and rather think about readability in terms of intention-revealing variable names (and functions).

Once it gets messy it's time to refactor:

• rename variables
• introduce new variables/functions

Example

subtotal = price * (100 + tax_ratio) / 100

vs.

tax = price * tax_ratio / 100
subtotal = price + tax

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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()
    };

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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