Do you still limit line length in code?

Question

This is a matter on which I would like to gauge the opinion of the community: Do you still limit the length of lines of code to a fixed maximum?

This was certainly a convention of the past for many languages; one would typically cap the number of characters per line to a value such as 80 (and more recnetly 100 or 120 I believe). As far as I understand, the primary reasons for limiting line length are:

• Readability - You don't have to scroll over horizontally when you want to see the end of some lines.
• Printing - Admittedly (at least in my experience), most code that you are working on does not get printed out on paper, but by limiting the number of characters you can insure that formatting doesn't get messed up when printed.
• Past editors (?) - Not sure about this one, but I suspect that at some point in the distant past of programming, (at least some) text editors may have been based on a fixed-width buffer.

I'm sure there are points that I am still missing out, so feel free to add to these...

Now, when I tend to observe C or C# code nowadays, I often see a number of different styles, the main ones being:

• Line length capped to 80, 100, or even 120 characters. As far as I understand, 80 is the traditional length, but the longer ones of 100 and 120 have appeared because of the widespread use of high resolutions and widescreen monitors nowadays.
• No line length capping at all. This tends to be pretty horrible to read, and I don't see it too often, though it's certainly not too rare either.
• Inconsistent capping of line length. The length of some lines are limited to a fixed maximum (or even a maximum that changes depending on the file/location in code), while others (possibly comments) are not at all.

My personal preference here (at least recently) has been to cap the line length to 100 in the Visual Studio editor. This means that in a decently sized window (on a non-widescreen monitor), the ends of lines are still fully visible. I can however see a few disadvantages in this, especially when you end up writing code that's indented 3 or 4 levels and then having to include a long string literal - though I often take this as a sign to refactor my code!

In particular, I am curious what the C and C# coders (or anyone who uses Visual Studio for that matter) think about this point, though I would be interested in hearing anyone's thoughts on the subject.

Edit

Thanks for the all answers - I appreciate the variety of opinions here, all presenting sound reasons. Consensus does seem to be tipping in the direction of always (or almost always) limit the line length.

Interestingly, it seems to be in various coding standards to limit the line length. Judging by some of the answers, both the Python and Google CPP guidelines set the limit at 80 chars. I haven't seen anything similar regarding C# or VB.NET, but I would be curious to see if there are ones anywhere.

Answer 1

Now that I can squeeze the font size down to be quite small, I prefer not to place arbitrary limits on text length. I want to see as much code as possible on my screen.

Having said that, I will say that excessively long lines of code can be difficult to understand, so I make liberal use of line breaks and indentation, along with white space, to improve readability,

Answer 2

I still stick to 80 chars wide unless I know I am the only person who will be looking at the code. Exceeding the limit is a great indicator of ugliness (e.g too much nesting, or trying to do too many things on one line).

I have a wide screen display, but I actually prefer to rotate it and use it as a tall screen - more lines of code is much better than wider lines.

It's also harder to cross-read lines when they're short.

I also like to use vim over ssh connections quite a bit, and I use a laptop with a pretty small screen at times. On those days, I appreciate my 80 column limit that much more.

Answer 3

I certainly try to limit the length of the line (120 currently), but just for readability. I even use a trick to force myself to do it in Visual Studio:

http://blog.feradz.com/2009/02/add-line-length-marker-in-visual-studio/

As for deep levels of nesting: I remember reading coding guidelines for writing code for Linux kernel, I believe created by Linus himself. The guidelines included the maximum level of nesting in a function (3 as I remember) with the comment, that if you need more levels than 3, you shouldn't write kernel code ;)

Answer 4

Normally, I don't worry about this too much, especially not to the point where I'd actually set a fixed limit. Generally, I go by the actual readability in my mind. If I have trouble reading it all on one line, I'll split it. There are a couple of instances where I (almost) invariably do this -- methods with several parameters, including when using the automatic constructor technique in C#, and chained method invocations, such as when using IEnumerable extensions. I'll even do this when line length is not really an issue. Typically in the latter case, I will split the methods on the dot and put each method on a separate line.

 var query = table.Where( s => s.something ).Select( t => t.property ).FirstOrDefault()

becomes

 var query = table.Where( s => s.something )
                  .Select( t => t.property )
                  .FirstOrDefault()

Answer 5

I set my character-length per line to 100, even then I don't reach it too often.

If you are writing longer lines of code your code is a mess. Breaking up long strings, \n and indenting long arguments for functions and so on just keeps things clean. Im sure there are some 80-char screens still in use but this isn't the main reason.

Programming is a set of short sequential statements, not long gangly ones.

Answer 6

I limit textwidth to 80. This is because, I do not like long lines wrapping around. If a long line wraps around, it will be difficult to navigate using Vim (and possibly other editors, without using a mouse/pointing device). I will have to try n| (in Vim) where n stands for the trial-and-error column number. If the line is shorter a ^ (to go to the first column with text) and $ (to go to the last column) action will be sufficient. So, I think textwidths are relevant today too.

Just my observation.

Answer 7

There's an option to switch on line wrapping which is most useful. Some APIs require longer lines... these include the CCR library from Microsoft and I fairly frequently unavoidably go beyond your arbitrary limits when writing LINQ and their method chain equivalents. Of course there are ways to format a single line such that they are spread over many.

Answer 8

I don't have a hard and fast rule here. Like you said, if there's a long string literal, who cares if you have to scroll to see the whole thing. My center monitor is 27.5 inches so what I like will certainly differ from what someone with 19 inch monitor will like. I don't like code that has so many line breaks that you have to constantly page up and down just to see a few "lines" of code.

Answer 9

Limit to 80 characters. The Google cpp coding standards have a good explanation why, but my main reason is the "parallel editors" one.

(Edit: look up "Line Length" in the google link, failed to direct-link for some reason)

Answer 10

Virtually all the time I work on code, I have multiple windows open. Documentation, other parts of code, diff output, reference websites. Limiting myself in code width means I can organize windows side-by-side, instead of having to alt-tab through them (which can get confusing as hell).

That's my #1 reason for limiting line length. Not having to scroll horizontally is another convenience.

Answer 11

I still limit lines to 80 characters:

• This way I can view three files at the same time, each in a column side by side. (This proves especially useful when doing a three-way merge.)
• I'm sure the code will be readable when I print it or put it on a web page.
• It's the standard limit for Python code.

Answer 12

Using my crappy old LCD monitor in portrait orientation enables me to view two files side by side with more than 120 lines visible at a time.

In gvim, textwidth=74 for all code.

Answer 13

Two reasons why I stick to 80 columns wide for my source:

1. Remote editing, often through an SSH session, and particularly on windows with something like putty. Even in this day and age, its sometimes difficult to actually get more than 80 chartacters.
2. comfort. With shorter lines, I can set the size of the text quite large, and then I can stare at the code for a long time with neither eyestrain nor backstrain (from leaning forward in my chair). When I need to see a bit more, I temporarily zoom out and usually open three more editors to see what's calling what.

Answer 14

I usually cap around 100 columns of code.

My rule of thumb is, If I can't fit it onto my screen without horizontal scrolling, reformat.

If I'm doing something likely to be printed, I will format to fit printed material.

Answer 15

The effect of indents could have an impact on maximum line length.

If tabs are used for indenting code you sometimes have to consider people may be viewing with a different number of chars/tab.

Sometimes after a couple of indent levels an 80 or 100 character limit can result in the actual space for code being reduced a bit.

Of course too much nesting isn't ideal but is often unavoidable (exception blocks, nested loops).

On idea is to have something like an 80 char limit but only start counting from the first non-whitespace character in the line - so each sub-block of code can use an optimal amount of screen real estate.

As many comments here have stated - it's all about readability.

Answer 16

Something nobody mentioned is email. If you send code snippets via email or post them in a newsgroup it is good if you can prevent line wrapping. If the lines in your code are already shorter than 80 characters you don't have to reformat them.

Another thing: No matter what your convention is, stick to it. Nothing is worse than unnecessarily reformated code, because this makes diffing a nightmare.

Answer 17

I try to format my code to fit readably in 80 columns. (I use chiefly Java and Python with 4 spaces per indentation level.) On balance, I consider it a win for readability. I also do it for tooling reasons:

• it leaves plenty of space for outline views, project trees and other dodads in eclipse.
• I can fit 160 columns across my 1024 pixels using my favorite font, so I can get two documents on the screen at once on my netbook this way.
• svn blame is easier to fit onto the screen if the source lines aren't already pushing the limits.

---

Complex deeply nested expressions are a problem, of course. I try to break them across lines in a way that does not impede readability, or simplify into a sequence of simpler expressions using a temporary variable.

Recently I find myself using end-line layout more (Emacs makes this easy). I was "against it" for many years stemming from reading the first edition of Code Complete.

some_variable = some_function(foo,            // an exaggerated example of
                              bar(one, two),  // end-line layout
                              baz);

I guess, what it boils down to is that I've come to view code layout as a two-dimensional layout problem. I try to use vertical alignment to communicate the structure of my code when it seems sensible. Yes, this can conflict with 80-column rule, in which case line length has priority and I revert to a more conventional layout:

some_variable =                         // for assignments that are too long, tend
    some_function(foo, bar(one, two),   // to leave the target variable on a line ending
        baz);                           // with the assignment operator.

I find that automatic code formatters, like the one built into Eclipse make complete hash out of my code regardless of how I configure them. If they break expressions, they do so in a way that is deeply mystifying and use indentation that hinders readability more often than not. And have you seen what most code formatters will do to use of "fluent" interfaces? I won't touch them.

builer().addChild(1)
        .addChild(2).withColor(BLUE)
        .metaInformation().addEntry("foo").withValue("bar")
        .build();
====>
builder().addChild(1).addChild(2
   ).whithColor(BLUE).metaInformation()
             .addEntry("foo")
                       .withValue("bar")
                                                 .build();
//... or something similarly atrocious.

This is also why I find the idea that the solution to differing code formatting preferences on a team is to have tools format to personal preferences on checkout and then format back to standard on checkin to be completely wrong-headed. Anyone who cares so little about code formatting as to be satisfied with the garbage an automatic formatter produces, should just get with the program and conform to a common style agreed upon by the team.

---

Years ago, when I programmed mostly in Oberon, my approach was completely different. Oberon is traditionally programmed in a styled text editing environment with proportional fonts using real tabs for indentation. This makes games with vertical alignment fairly pointless. (Though you could do some cool stuff since you have all the formatting possibilities of a simple word processor at your disposal including the ability to set your own tab stops, embed tables, graphics and other elements.)

Answer 18

In a reasonably condensed lannguage like C or C++ I'll cap it to 80 character line widths.

I also prefer doing indentation with tab.

I understand the need to be able to view code at 80 width, but I'm willing to pay a price to get it: my rule is it must fit on 80 width at with tabstops set to 2. Most people use larger tabstops.

In .NET or Java, where standard library class and function names are so long, and "overhead" indentation easily ends up three levels before you even start, it's a losing battle.

Answer 19

I don't try to limit the line length unless it gets too long. (As in sticking over the edge of my widescreen monitor... ;P)

However, the main way I do so is by writing lines like this:

ConfigDir = Path.Combine(
    Path.GetDirectoryName(Application.ExecutablePath),
    "Config"
);

Which also provides easy readability.

Answer 20

Int32 padding = 25; Int32 lineLength = Screen.AllScreens[ActiveDisplay].WorkingArea.Width - VisualStudio.SolutionExplorer.Width - padding;

Most of the time I generally cut off my lines when they hit the edge of the scrollbar, -~25 pixels or so.

I will also condense long methods with a lot of parameters by putting a new parameter on each line, indented of course.

I will essentially fill up the editor window until it spans the monitor width. As for printing, doesn't really matter, if you print from Visual Studio it has the nice linebreak arrows it displays

Answer 21

I do not limit the line length as most editors support breaking up the line per the users preferences if they want to wrap or not. Personally I run 3 monitors so I have the space. If I format it for the user, then it is sort of forcing them to view it how I want, not how they want.

Answer 22

Unless you want to print it out, the only reason you would want to have a line limit would be to be able to display two files side by side on one monitor. I can't imagine doing that so I would scrap the requirement.

Answer 23

I try to limit my lines to 80 chars, but if I exceed for some reason, I don't make big deal out of it: most people have windows a lot larger than 80 columns, so that won't bother them too much anyway.

Answer 24

I split windows horizontally into two in Emacs, so i have to limit my line length within 90~100 characters still

Answer 25

Unfortunately, I routinely have to deal with legacy source code where in a few cases there is a single line of source code that is more that 3 THOUSAND CHARACTERS WIDE! Seriously.

These long lines are almost always C++ constructor functions, in the form of:

SomeClass::SomeClass( int a, int b, string c, double d, string e, double f ) : SomeBaseClass( a, b ), m_c( c ), m_d( d ), m_e(e), m_f(f), m_g(), m_h( a * e ), m_i( f*e ), m_j( c + " " e ), m_k(), m_l() { }

except with longer parameter names and longer member variable names and more of them.

In cases like these, a simple maximum column width rule doesn't help at all. At least not after the fact.... The problem is that the class has too many concerns and that refactoring needs to occur... badly. I guess that if the rule of a maximum line width of 80, 120 or even 160 bytes were given, it would somehow compel the original programmer to realize that something deeper is wrong.

Answer 26

My text editor (geany) has a reference line that you can set, I think the default is 72 characters. I do not line limit to that, but at the same time dont go crazy long either. If/when code is cut and pasted into bug report software or emails it gets wrapped so that is more of a driving factor than anything else for me.

Answer 27

Yes, i do. We prefer limited line length because we also develop at our customer that has smaller monitors and we don't want to change the sourcecode there. Therefor we limit the length of our code.

We also limit the line length in our unit tests for the same reason.

Answer 28

I let resharper autoformat my code. You can set your maximum line length and it will split llines bigger then our limit. Default it is set to 120 characters.

You can also visualize the border to give you an idea when your lines are too large.

Answer 29

Not out of any sense of tradition, I typically stick to 80 chars per line to make it more readable. It's the same principle as limiting line-lengths on a website - studies prove that people struggle to effectively read longer lines.

That, plus, I like to have my code open over the top of a web browser so I can easily scan across any docs, (or more likely Twitter/Facebook... :s)

Answer 30

What nobody (at-least the top voted ones, that I read) seems to have pointed out is this:

Most of the lines of code are under 60 columns. There are occasional cases (<5% of lines) where the code extends beyond this normal limit.

If you have a few lines over 120 chars, either of this will happen:

1. The editor displaying the code will consume entire screen, even tho' the code in the second part of the screen is there in just a few lines. It reduces the amount of code U can see on the screen at once.

2. The editor is in the wrap mode and arbitrarily, at the end of a particular column, split the code to next line. It makes it hard to read.

Either way, you are interrupting the programmer from the flow.

Answer 31

I try stick to 80 wide, and I try to limit my nested functions within the same command.

There's nothing more irritating than following a stack trace to find the source of the Exception is line 23, which goes on to read as:

23: Object myObj = ob1.kenobi().speak().scratchMyAss().getLightSaber().jediMindTrick();

Great, now which method call on line 23 threw the exception?