C# coding style - line length / wrapping lines

Question

Does line wrapping help with code readability?

Is there a generally accepted etiquette for using line continuations?

Why use this:

SomeMethod(int someInt, Object someObject,
   String someString, bool someBool)
{
    ...
}

Instead of this:

SomeMethod(int someInt, Object someObject, String someString, bool someBool)
{
    ...
}

Edit: re-worded my question from line continuation to line wrapping

Answer 1

Line continuations are not used in C#, since an explicit line terminator (;) is required.

If you're asking, in terms of style, whether it's a good idea to break a line into multiple lines, that's debatable. The StyleCop rules force a line to either be defined on a single line, or for every element to be on a separate line. I personally think this is a good guideline, and I usually choose to break a line completely into its parts if it's too long to fit into a good 80-90 character wide editor.

---

Edit in response to your new question:

In this case, I would follow the guidelines above. Personally, in your specific case, I'd leave this on one line:

SomeMethod(int someInt, Object someObject, String someString, bool someBool) 
{ 
    ... 
} 

This is a nice, short moethod declaration, and I see no reason to split it. I'd only split it if the number of arguments, and the lengths of the types, became far to long for one line of text.

If you do split it, however, I'd split it into separate lines for each argument:

SomeMethod(
    int someInt, 
    Object someObject, 
    String someString, 
    bool someBool) 
{ 
    ... 
} 

This way, at least it's obvious how and why it's split, and a developer won't accidentally skip one argument since two are on a single line.

Answer 2

Now that we've clarified that this isn't to do with actual line-continuation characters and simply line-wrapping - you tell me. This:

IEnumerable<int> orderIDs = context.Customers.Where(c => c.CustomerID >= 1 && c.CustomerID <= 10).Select(c => c.Orders).SelectMany(o => o).OrderBy(o => o.OrderDate).Select(o => o.OrderID);

Or this?

IEnumerable<int> orderIDs = context
    .Customers
    .Where(c => c.CustomerID >= 1 && c.CustomerID <= 10)
    .Select(c => c.Orders)
    .SelectMany(o => o)
    .OrderBy(o => o.OrderDate)
    .Select(o => o.OrderID);

Which would you rather read?

Answer 3

I think that the limit of line length has gradually been lengthening (or disappearing) over the past few years as everyone gets widescreen hi-res monitors and rarely print out code anymore. None of the projects I've worked on have an official guideline, we just use common sense and linebreak at roughly a editor window's width (everyone uses the same basic Eclipse window layout at about the same resolution). I see no problems with this method.

Answer 4

I favour breaking lines at logical points. The reason is to help with source code control differencing and merging functions. I have found that understanding changes in such an environment is much easier if statements with many elements are broken onto multiple lines.

Monitors are large. But you can find youself working on a laptop computer and performing a merge in which you have base, source and target branches in separate windows across the screen. Count the characters: each of these windows on a 17-inch laptop is only about 55 characters wide.

If you are working remotely you will discover that horizontal scrolling is not well optimized, and you may well think a few reproachful thoughts about programmers who write functions with 15 parameters on a single line.

So think about ALL the ways you have to work on the source code, and break lines at places which serve ALL your needs.

Answer 5

Personally, I like to be able to "see" everything. Then again, I have a pretty decent monitor. But seriously, I like nice and small functions vs. gigantic functions with nested "if" statments. Same with a lines of code.

At the end of the day, it comes down to personal preference and whatever you and your team members decide. Be consistent. And favor readability for the next guy that looks at your code.

Answer 6

Some years ago I read Damian Conway's Perl Best Practices. Here's a link below

Perl Best Pracices on Google Books

There's a whole chapter there dealing with Code Layout. All my feelings about code layout are summed up in his writing. I highly recommend that chapter. It can be easily applied to C#.

I've been trying to stick to his rules for whatever language I might be using : C#, Java, Perl, JavaScript, VBScript, VB, PHP,...

In this book, Conway suggest to use 78-column lines. I've got to admit I broke the rule and sticked to 80 but I think it's OK.

I've integrated this rule to every editor I use (Notepad++, Komodo, Vi, Vim, Visual Studio 2005) in order to have a visual guideline showing this limit.

Some of you might wonder how to show a guideline on VS, huh?

Well I found it to be not so obvious. In fact, you have to actually create a string parameter in the registry. Here's a post I found on SO about it. Hope it helps.

Adding a guideline to the editor in Visual Studio