If you break long code lines, how do you indent the stuff on the next line? [closed]

Question

Sometimes you have to write in your source long lines, that are better to break. How do you indent the stuff ceated by this.

You can indent it the same:

very long statement; other statement; 

That makes it harder to differentiate from the following code, as shown in the example. On the other hand you could indent it one level:

very long    statement; other statement; 

That makes it easier, but it can happen, that the long line is the start of a nested block, that you want to indent, like this:

if ((long test 1) &&    (long test 2) &&    (long test 3)) {    code executed if true; } 

In this case again it's hard to read. The third possibility I can think of, is to not break long lines at all, modern editors can handle it and create soft linebreaks. But with another editor you have to scroll sideways and you cannot influence the position, the editor breaks your long line.

What possibility do you prefer? Do you have other ideas to solve this? Can you support your preference with a good justification?

Answer 1

I like braces on their own line because I fine it easier to see the condition and inner block all as one item (if you know what I mean):

if ((long test 1)     && (long test 2)     && (long test 3))  {     code executed if true; } 

and I like starting additional conditional lines with what the condition is because I find that the "joining" condition is very important and it tends to get overlooked at the end of the previous line.

I also try and indent such that the effect of parenthesis are obvious (though trying to avoid long conditionals is generally a good thing).

I try and structure stuff so that I can easily "scan" for "stuff" :)

Answer 2

You should try to prevent writing lines longer than 80 characters rather than breaking them:

• Try to minimize indentation by converting conditions and encapsulating code.

Linus Torvalds: If you need more than 3 levels of indentation, you're screwed anyway,
and should fix your program.

This also has the side effect of making you code much more readable, besides that the conditions are the other things you encapsulate are ready to be used elsewhere.

bool encapsulatedLongCondition() // Add some parameters {   if (!condition1)     return false;    if (!condition2)     return false;    // ... (Other conditions)    return true; }      if (encapsulatedLongCondition()) {   // ... (Call some methods, try not to introduce deeper if/loop levels!) } 

Simplifying your condition through boolean algebra and trying to invert the condition and return value can help a lot. :-)

See also: Can you simplify this algorithm? See also 2: Refactor for C# has the ability to assist you with this. ;-)

• Use type definitions and try to avoid long names

A simple example, imagine how long it would be using Days without typedef with longer names in another container.

struct Day {   // Some data }; struct Event {   // Some data }; typedef list<Event> Events; typedef map<Day, Event> Days; // Some other container that would else be long... 

• ... (You should try to analyze why your line is long and find a solution for it)

Hope you get the general idea, this way you won't need to come up with a dirty line break. ;-)

The only place where I would see long lines occur is in the prototypes of your functions or when calling them, there you should just try to break after the last possible comma and continue on the next line. Rather than doing it after each and wasting multiple lines making scrolling bloated and your function stand out too much... You could place the return type on the line before the function name if you happen to frequently see these long lines.

void longFunctionName(ParameterType1 parameter1, ParameterType2 parameter2,                       ParameterType3 parameter3, ParameterType4 parameter4)