When you're in Python or Javascript, you should always put binary operators at the end of the previous line, in order to prevent newlines from terminating your code prematurely; it helps you catch errors.

But in C or C++, this isn't an issue, so I'm wondering:

Is there any reason for me to prefer the second version to the first?

return lots_of_text
       + 1;


return lots_of_text +

(For example, does one of them help prevent other kinds of errors? Or is one of them considered more readable?)

  • 2
    No you shouldn't do that in Python, mostly because does not have the effect you claim it has. A trailing operator doesn't cause a line continuation; a backslash or having unclosed parentheses, brackets or braces does.
    – user7043
    Aug 12 '12 at 2:45
  • @delnan: I (very carefully) never said it causes a line continuation. I'm aware you still need enclosing grouping characters. I said it helps prevent mistakes with your line ending prematurely, which it does, by giving you an error.
    – user541686
    Aug 12 '12 at 2:46
  • I see, but it doesn't do that either. At least I've never seen it happen (and I strictly follow PEP 8's rule about putting newlines after operators) and I cannot imagine non-contrived code which is valid with the newline before the operator but not after the operator. For example, code like in your first snippet also errors (due to indentation). Does anyone not add indentations when splitting a line?
    – user7043
    Aug 12 '12 at 2:49
  • 5
    Not sure why this was downvoted. It seems like a reasonable coding style question. Aug 13 '12 at 7:09
  • 2
    @delnan: pep8 has been updated: python.org/dev/peps/pep-0008/…
    – Neil G
    Jul 26 '16 at 11:08

As you can see from the answers, there is no consensus on this matter. Unless you work in a team, use what you are more comfortable with.

I prefer inserting a newline before operators.

Whenever I have to break lines, I usually put at most one term of the same "level" on a line:

Newton's law of gravitation in Python:

force = (
    * mass_1
    * mass_2
    / (distance * distance)

Compare this to:

force = (
    gravitational_constant *
    mass_1 *
    mass_2 /
    (distance * distance)

I want to know, that I "divide by distance squared", I don't want to know, that "mass_2 gets divided", because that's not how I think of mathematical expressions.

Further, I usually want to know first, what I am doing (operator), before I care about what I do things with (operands).

Or consider this convoluted SQL statement:

  a = 1
  AND b = 2
  AND c = 3
  AND ( -- or put the OR on one line together with the AND
    d = 3 
    OR e = 1)
  AND x = 5

This allows me to see how the individual conditions are connected very easily, just by skimming from top to bottom without having to read every line until the end to find the operator as opposed to:

  a = 1 AND
  b = 2 AND
  c = 3 AND
    d = 3 OR
    e = 1) AND
  x = 5

I think about the former in terms of "X is true", then I amend that by saying: "AND this is also true" which feels more natural to me than the other way around. Further, I find the first much easier to parse visually.

Or a PHP example:

$text = "lorem ipsum"
      . "dolor sit amet, "
      . "consectetur adipisicing elit, "
      . "sed do eiusmod tempor";

Again, I can just skim read vertically to see I'm simply concatenating text, because most of the time I feel that I do not actually care what is inside the strings/conditions.

Of course, I would not apply this style unconditionally. If putting the newline after an operator seems to make more sense to me, I would do so, but I can't think of an example at the moment.

  • Added missing parenthesis to first example. Aug 13 '12 at 18:14
  • 1
    +1: exactly right; mathematics is always typeset so that continuation lines start with an operator. Aug 13 '12 at 18:16
  • +1 for the same reasons you describe, but your PHP example looks quite odd to me. Shouldn't those concats just be ., not .= ?
    – Izkata
    Aug 13 '12 at 18:31
  • @Izkata oh yes, you are correct of course. Thanks. kevin: The parentheses were correct ;) I just aligned them with force
    – phant0m
    Aug 13 '12 at 21:10

I almost always break lines before binary operators in order to make clear to readers of the code that this is the continuation of an expression and not the next statement. This is important if the next statement would normally be indented. For example, consider an if statement that has a complex conditional expression:

if (first_part_of_condition &&
    second_part_of_condition) {

The second part of the conditional expression is easily confused with the first statement of the then-part. This can be quite confusing if the first part of the condition is long and the && ends up way off to the right. Compare this with the alternative:

if (first_part_of_condition
    && second_part_of_condition) {

This looks a bit odd but it makes it quite clear that the second part of the condition is not the beginning of a statement.

I do this in others contexts too but the if-statement is the most important, as the indentation is ambiguous. Of course, one could change the indentation or brace placement, but this looks odd too.

tl;dr the left end of the line is more significant to quick reading comprehension, so putting the operator on the left end is a more prominent marker that this is a continued expression, not a statement.

  • Interesting thought but I stil find this pretty confusing (especially when done with + and - which could also be understood as unary prefix operators). The usual solution to make the continuing lines stand out is to indent them more (i.e. by two levels). Aug 13 '12 at 9:54
  • "The second part of the conditional expression is easily confused with the first statement of the then-part.": This does not happen if you align the "{" and "}" vertically (same column) to make the beginning and the end of the block stand out more clearly.
    – Giorgio
    Aug 13 '12 at 10:30

I'd always use the first. You want it to be clear what you are doing with that 1 there. If I saw that and there was a wall of text above that 1 I'd have no idea what was going on as far as that 1's usage.

# The first
return lots_of_text
       + 1;

The '+' being next to 1 makes it clear that at a minimum I am doing something with the 1 in question rather than it hanging out going "I'm all in your code dude..." for no apparent reason.

  • seconded...........
    – James
    Aug 12 '12 at 2:51

I feel that it helps reading comprehension tremendously when a line indicates that the statement continues in the next line by having the binary operator at the end, and thus rendering the statement incomplete. The missing semicolon isn’t enough for me to immediately understand that.

This may simply be a question of habit but unless you work exclusively in languages which require the semicolon (which I find pretty unrealistic given the pervasiveness of shell scripts, makefiles and languages such as Python) you probably won’t have that habit either.

EDIT: Giorgio makes an excellent point in the comments: this usage echoes common punctuation, both in mathematics and natural languages. You’d write

I sink,
therefore I swam

You would not write

I sink
, therefore I swam

  • 3
    +1: I also tend to read the + at the end of the line as a comma separating two items in a list of operands. For this reason I prefer to put the + at the end of a line as I would do with a comma (I would never start a line with a comma).
    – Giorgio
    Aug 13 '12 at 10:32
  • @Giorgio This point is so excellent that I’ve stolen it for my answer. I hope you can forgive me. Aug 13 '12 at 10:36
  • Go ahead: I feel honoured. ;-)
    – Giorgio
    Aug 13 '12 at 10:38
  • 9
    Code is not English, and I think it's a false analogy to use English syntax rules as a way to justify coding conventions. I don't like the trailing operator style, but I admit Konrad has a good point about languages like Python. Aug 13 '12 at 12:02
  • 4
    In mathematical typesetting, the line break is always before an operator, never after. In the prosaic example, the operator is "therefore". In English prose, commas are essentially breath marks. Aug 13 '12 at 18:01

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