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.

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;

versus

return lots_of_text +
       1;

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

share|improve this question
    
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. –  delnan 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. –  Mehrdad 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? –  delnan Aug 12 '12 at 2:49
    
@delnan: It's actually very easy to accidentally screw up the indentation with your text editor, e.g. when bulk-editing or doing rectangular selection. And if/when that happens during maintenance, you won't get an error in the first case and it will silently slip by you, but you'll get a nice error in the second case. –  Mehrdad Aug 12 '12 at 2:55
4  
Not sure why this was downvoted. It seems like a reasonable coding style question. –  Stuart Marks Aug 13 '12 at 7:09
show 5 more comments

closed as not constructive by gnat, Walter, kevin cline, Mason Wheeler, Mark Trapp Aug 21 '12 at 7:43

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

4 Answers

up vote 10 down vote accepted

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 = (
    gravitational_constant
    * 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:

WHERE
  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:

WHERE
  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.

share|improve this answer
1  
+1 this is a really convincing way of putting it. –  Mehrdad Aug 13 '12 at 11:51
    
Added missing parenthesis to first example. –  kevin cline Aug 13 '12 at 18:14
1  
+1: exactly right; mathematics is always typeset so that continuation lines start with an operator. –  kevin cline 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
add comment

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) {
    statement_within_then_part;
}

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) {
    statement_within_then_part;
}

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.

share|improve this answer
    
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). –  Konrad Rudolph 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
add comment

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 '+' 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.

share|improve this answer
    
seconded........... –  James Aug 12 '12 at 2:51
add comment

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

share|improve this answer
2  
+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. –  Konrad Rudolph Aug 13 '12 at 10:36
    
Go ahead: I feel honoured. ;-) –  Giorgio Aug 13 '12 at 10:38
3  
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. –  M. Dudley Aug 13 '12 at 12:02
1  
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. –  kevin cline Aug 13 '12 at 18:01
show 5 more comments

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