The 80 column limit, still useful?

Question

Related:

• While coding, how many columns do you format for?
• Is there a valid reason for enforcing a maximum width of 80 characters in a code file, this day and age?

I mostly use C, however this question is language agnostic. Its also subjective, so I'll tag it as such.

Many individual projects set their own various coding standards, a guide to adjust your coding style. Many enforce an 80 column limit on code, i.e. don't force a dumb 80 x 25 terminal to wrap your lines in someone else's editor of choice if they are stuck with such a display, don't force them to turn off wrapping. Both private and open source projects usually have some style guidelines.

My question is, in this day and age, is that requirement more of a pest than a helper? Does anyone still login via the local console with no framebuffer and actually edit code? If so, how often and why cant you use SSH?

I help to manage a few open source projects, I was considering extending this limit to 110 columns, but I wanted to get feedback first. So, any feedback is appreciated.

I can see the need to make certain OUTPUT of programs (i.e. a --help /h display) 80 columns or less, but I really don't see the need to force people to break up code under 110 columns long into 2 lines, when its easier to read on one line.

I can also see the case for adhering to an 80 column limit if you're writing code that will be used on micro controllers that have to be serviced in the field with a god-knows-what terminal emulator.

Beyond that, what are your thoughts?

Edit:

This is not an exact duplicate. I am asking very specific questions, such as how many people are actually still using such a display. I am also not asking "what is a good column limit", I'm proposing one and hoping to gather feedback. Beyond that, I'm also citing cases where the 80 column limit is still a good idea.

I don't want a guide to my own "c-style", I'm hoping to adjust standards for several projects. If the duplicate in question had answered all of my questions, I would not have posted this one :) That will teach me to mention it next time.

Edit 2

question |= COMMUNITY_WIKI

Answer 1

It completely depends on the monitor you use. We have a 100 column standard. Which works great for our monitors.

You could argue if longer lines add any significant value. But you must not forget that this enables the use of longer (most of the time more descriptive) identifier lengths.

Answer 2

Very long lines are still hard to read - it's annoying ot have to scroll across the page, but that's all. For this reason I do stick to "sensible" line lengths, but not to a hard and fast rule. 110 would seem reasonable to me, why not try it out on one project first before rolling it out to all of them?

Answer 3

The issue is not the output device - the issue is readability. Take a look at a printed book - these have evolved over centuries to be very readable. You will find that the page width is much less than 80 characters, probably round about 60.

Answer 4

While the physical limitations of green screen terminals are largely gone, but was never the best argument for limiting line length.

The best comes from the world of print, it is hard to read very long lines of text, as the lines get longer there is an increased tendency for your eyes to skip up or down a line. This is why newspapers print in columns, and why books use relatively small page sizes despite this requiring more binding.

Short expressions are easier to understand; too much indentation is harder to follow.

Remember the most important consumer of the code is whomever will read the code, and he might just know where you live.

Answer 5

Its probably best to be pragmatic and only enforce an 80 column limit if it makes sense to do so...ie if a significant number of people need it to be at that limit. These days with large monitor sizes I don't think we need to be pedantic about 80 columns unless there was a specific need for it.

Answer 6

I think that the fact that we are now using fonts that are sizeable (albeit more often than not fixed-width) have made the 80 column limit irrelevant.

Not only that, but certain code readability standards will suffer from such limits, e.g., naming conventions wherein method names that fully describe what the method is doing without any sort of abbreviation (think AssignNumberToCustomerAndSetOrderStatus) eats up 80 characters quite fast.

Column width is still relevant, of course, to terminal-based languages such as COBOL, but other than in that case I can't think of enough reason to stick to the 80 character limit.

Answer 7

If you sit before a Full-HD monitor then 80 characters limitations is nonsense.

Especially if you follow the good style of self-explanatory names for variables and method names you will run into the problem that you code will grow down like crazy.

80 characters maybe good for pocket books to read on the way, but not for code.

My personal opinion that the reasonable width of code is up to ~1400-1500 pixels at normal font size. After that readability goes backwards.

Answer 8

80 characters a line, is a good guideline to aim at, for the readability and ergonomic reasons already mentioned. Always defer to common sense !

Answer 9

I've always done 80 (header files) or 100 (source files) when I was developing in C and C++.

For some reason, with C# I tend to need more space, therefore for now I have settled to 120 columns.

Answer 10

Source code does not appear only in 16/9 HD screens. It may be:

• printed in portrait mode,
• quoted in a book,
• displayed on a blog or on Stackoverflow.

I hate horizontal scrollbars which prevent me from reading a portion of code as a whole.

Answer 11

80-columns makes a lot of sense in any project. It makes it much more easier to have two related file windows opened side by side. Examples: viewing diffs and .h/.cpp pairs.

Answer 12

Yes, it's still useful. For reading code, I prefer to have a wide-screen pivoted by 90°, and everything > 80-90 lines of code becomes unreadable then. So you should keep this in mind. Moreover, I've seen already quite a few people with a dual-screen setup where they have one large screen and a smaller one next to it, tilted by 90° -- this setup is not as unpopular as one might think.

The other thing is printing code, not that you would do it often, but for debugging some more serious problems it can be really useful.

Answer 13

The main argument for the 80 column standard is readability. But I don't agree that shorter lines necessarily make code more readable if you read code on a screen. Printing code on paper (does anybody do this to any extent anymore?) is a completely different discussion.

I've seen unwanted behavior among programmers that want to cram full statements on single lines, in order to get nice predictable indentation. Giving variables extremely short names is only one example. I'd prefer giving programmers larger freedom when it comes to the number of columns if they instead use descriptive naming.

Another common argument is that short expressions are easier to understand, but that does not necessarily imply short lines. That is rather because the expression is simple.

If I had to set a limitation I would be quite generous and try to encourage other readability features also.

Answer 14

In Python you are more or less forced to use the 80 characters limit - if you want to develop software like Python itself or frameworks (e.g. Django).

Python Enhancement Proposal number 8 (PEP-8), "Style Guide for Python Code" says:

Limit all lines to a maximum of 79 characters.

It mentions the side-by-side windows argument.

---

I am using a little less, 77 characters, no matter the language: Perl, C++, C#, VB.NET, Python. One reason is to be able to use a large font without the need to scroll.

Answer 15

I think it is utterly ridiculous and against general principles of usability and accessibility, which mandate that the user agent should decide how the content is displayed. The fact that most user agents are rubbish at displaying wrapped code does not mean that we should play along and split lines according to some random rule; instead, make the user agent better.

Consider, of all things, VBA code:

sSQL = "SELECT unicorns FROM "
sSQL = sSQL & "TheTableOfMythicalBeasts "
sSQL = sSQL & "WHERE horns = 1 "
sSQL = sSQL & "ORDER BY beauty DESC "

Also written as:

sSQL = "SELECT unicorns FROM " _
       "TheTableOfMythicalBeasts " _
       "WHERE horns = 1 " _
       "ORDER BY beauty DESC "

Or just plain written as:

sSQL = "SELECT unicorns FROM TheTableOfMythicalBeasts WHERE horns = 1 ORDER BY beauty DESC "

There is massive danger of a bug occurring because I forgot a space at the end of the first or second statement, but nearly none in the single line version. The environment should figure out a sensible way to display a single statement so that it is readable; as with HTML, the content provider (coder) is usually the worst person to presume what is right for another user. I agree with coding for readability in terms of variable names and indentation, but column width is a personal preference best chosen by the recipient, as with font face/size.

Answer 16

In C#, Java and other recent languages, which have additional name-space, class and other overhead indentations, 100 columns (+/- 10) seem to fit well with 4 space indentation levels. Considering this on a wide screen with a 1440x900 or greater resolution, using a development environment with a sidebar permanently open.

In traditional functional languages, like C, which may be developed on an environment with a smaller screen, 80 columns provide enough width for comfortable code writing while at the same time avoiding horizontal scrolling on the more limited environments.

Answer 17

I'm going to go against the grain here and say no.

Because: there is a case for and against, and a code editor should be able to wrap(well) automatically to handle both cases. Also, by manually wrapping you are eliminating what could be a massive advantage of having wide and/or multiple monitors.

• Shorter lines are good for reading/understanding small chunks of code because you are reading and understanding each line. But even then, at 3 levels of 4 space indention you've lost 12 characters and you're down to 68 characters which is not much given modern symbol naming conventions.

• For understanding large amounts of code, I'd say wrapping makes the code much more difficult to read. IMO ideally for reading large amounts of code, you want it to almost look like a chart/spreadsheet, or many small spreadsheets. Wrapping makes field columns overlap which is hard to read.

Consider the following wrapped assuming 68 characters:

item0->setConfiguration( image0.height(), image0.width(), image0.pixelDepth() ); 
item1->setConfiguration( image1.height(), image1.width(), image1.pixelDepth() );

vs

item0->setConfiguration( image0.height(), image0.width(), 
                         image0.pixelDepth()              ); 
item1->setConfiguration( image1.height(), image1.width(), 
                         image1.pixelDepth()              );

---

I really believe that the deciding factor is that it should be fairly easy for code editors to include a feature that has wrapping rules.

You definitely don't me started on tab vs spaces...

Answer 18

Better this way (notice where is the comma) In this way anybody who read the code quickly understands that the line is another parameter of the function above.

item0->setConfiguration( image0.height(), image0.width()
                       , image0.pixelDepth()              ); 
item1->setConfiguration( image1.height(), image1.width()
                       , image1.pixelDepth()              );

In C codes the main information is within the first characters and a quick reading does not have to read whole sentences to understand what the code is doing. For example, if it is function call doSomething(… the rest are parameters with relative less importance ); The important thing is that is going to do something, we usually do no deep into the parameters unless we have to.

I disagree with the argument that limiting the length to 80 characters makes the code easier to read, because we do not read codes. Most of the time, we make quick looks moving the scroll up and down searching for pieces of codes that do a particular task or trying to have a general understanding of what a piece of code does without get confused on the details. A code is not a newspaper, neither a book; we do not have to read whole sentences, because in any decent code have thousands of lines, and details are overwhelming.

The only reasonable reason why a code would be limited to 80 characters is for printing and show the code in web pages. But there is a danger on that, because people tend to use acronyms and short names in order to fit in one line. The most frustrated codes are those like this:

it->sCon( im0.h(), im0.w(), im0.px() );

instead of

item0->setConfiguration( image0.height(), image0.width()
                       , image0.pixelDepth()              );