How and where to break long lines of code?

Question

Possible Duplicates:
Where to wrap a line of code, especially long argument lists?
Coding standards and line length

Hi,

• Where do you break long lines of code? (Example: before or after an operator)
• If it is a long string, do you split the string into substrings?
• What other cases exist when breaking long lines?

Answer 1

Couple of options:

1. Set a standard with your peers.
2. Print width.
3. Screen width.

-Cheers.

Answer 2

Where a statement is long enough to warrant breaking I will try to break it at one line per "semantic block", ensuring that no individual line could be mistaken for a separate statement (e.g. start with a operator (even if it's a dot) rather than end a line with an operator). I'll also indent to denote any logical hierarchy if one is apparent.

When I say semantic block I tend to find that there is usually some sort of pattern to a long statement that allows you to divide it into a couple of processes. They could be their own lines but sometimes they're trivial enough to line-break, especially when you're using a chaining object.

Answer 3

This is personal preference only since the question is a subjective one, but I tend to follow these guidelines.

• Limit code to 79 characters where possible (this is just so it prints out nicely at a high enough font size for my aging eyes to read it). Usually I'll break them initially somewhere in the 60-range so that the inevitable editing of lines to fix problems doesn't mean I have to reformat a lot :-)

• Break the line as high up in the hierarchy as possible. By that I mean x = 1 * 2 + 3 * (4 + 5); would be broken at the first + in preference to anywhere else. That's because the highest level "elements" of the statement are x, 1 * 2 and 3 * (4 + 5).

• Use indentation intelligently to ensure that the following lines are seen as part of the first line. For example, if the first line of a three line statement starts with 3 tabs, the following two lines have 4 tabs.

Something like:

x = 1 * 2 +
    3 * (4 + 5);

or:

if (1 * 2 =
    3 * (4 + 5))
{
    doSomething();
}

That last one is usually the only time I put an opening brace on a separate line. Usually I would have:

if (1 * 2 = 3 * (4 + 5)) {
    doSomething();
}

but splitting it makes it look like the second line of the if is part of the block:

if (1 * 2 =
    3 * (4 + 5)) {
    doSomething();
}

which I don't like.

As for strings, where they are longer than my preferred width, I tend to break them up. C and its brethren make this easy since the compiler treats "abc" "def" exactly the same as "abcdef". Even if there is a runtime impact (like concatenating strings), I'll break them up but I'll still try to minimise such impacts.

Answer 4

From a historical point of view, this used to be the old 80 columns width due to the screen size. However, since that isn't typically the case always, I think it isn't essential to follow that strictly.

However, if you think about it, you don't really want to scroll across a screen to actually read the entire bit of code. Breaking it up is definitely a good idea, so sticking to the 80 columns does make it easier to read, if you went from your wide screen to your laptop.

This is how I split up stuff:

1) After an operator

if(longVariableName || someOtherVariable ||  
   nextVariable)  
{
   //Some code here.
}

When you are reading the code, breaking it up after the operator, means the last operation (|| in my example), was in your head, when you started to read the next operator. Makes it easier to read, understand and comprehend.

Answer 5

This depends on your chosen environment: your language, your standard IDEs, your coworkers, and what inherently looks pretty and easy to understand for you.

You didn't mention which of any of these you choose to follow. If you ever have to expect editing this code in a terminal window you can start with the classic standby: 80 characters -- more than that and some terminals and CLI editors break or wrap painfully. Many IDEs will provide a visual cue at the 80th column mark for just this reason. If you can reasonably expect everyone who is looking at the code will be using fully featured IDEs (Examples including: XCode, Eclipse, and MS Visual Studio) then this is less of a requirement for you.

In my experience all of the places prefer to avoid overly long lines even when we all were using IDEs that could autowrap lines. In my experience line wrapping is considered bad and disabled in all situations.

From a semantic context I try to break at clause points. Basically if the line will end within 120 characters I'm less likely to break it up if there aren't convenient locations. If it would otherwise be longer than 80 characters and there are identifiable clauses I break them up there.

A 'clause' as used here is an expression that could be cleanly parenthesized. Mathematical multipart expressions get broken up at the operator, with the operator the first thing on subsequent lines. When talking about a long logical block, as in an if statement or a while/for loop, the same thing applies, I break the statemnt up with the subsequent lines indented and the operator first.

If you're working on OSX with Objective-C XCode will help you out. It automatically will indent subsequent lines such that the ':'s are aligned evenly. This gives a potentially easy to read method call.

Effectively you should try longer line lengths for yourself and decide at which point things get difficult to understand. With written text (comments or fiction, both) I find that excessively wide columns feels like runon sentences and makes it easy to lose my place. When lines are longer than 100 characters in code it usually means that there are many clauses, and if you have to scroll right/left to read, then it's easy to lose the flow of what your code is trying to do. Finally, when you have roughly 100 characters in a line, you can have two code windows open side by side for compare/contrast/contextual information... etc. Long lines make that impractical.

Many coders will agree that with a neat and clean coding style that you are familiar with, you can often detect lines or zone that are complex or troubling by how they fall out of the norm. This is a nearly subconscious cue that lets you notice when a line or method needs some refactoring or some love. The nail that sticks out is the first to get the hammer (if I applied that folk law correctly). And overly long lines are clues that something needs to be simplified or commented upon.

Answer 6

Because modern IDE's support horizontal scrolling, I do not care much about how long a line is per se (unless my team does); only how simple it is to understand. But it seldom matters because I break things up into lines or methods to make them easier to understand, so the length per line automatically stays short.