share
Stack OverflowThe 80 column limit, still useful?
[+60] [25] Tim Post
[2009-04-14 09:25:19]
[ language-agnostic coding-style ]
[ http://stackoverflow.com/questions/746853/the-80-column-limit-still-useful ] [DELETED]

Related:

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

let's call them "related" and everyone should be happy. already voted to close, though. - Can Berk Güder
Perhaps this should be community wiki... - Daniel Rikowski
Edited to make it CW. - Tim Post
(1) 1234567890123456789012345678901234567890123456789012345678901234567890123456789‌​0.......... As you can see, SO on my browser wraps comments at ~80 characters. :) - muntoo
[+67] [2009-04-14 09:29:22] anon [ACCEPTED]

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.


(21) Indeed, but code is not meant to be read the way we read sentences. If you have a long descriptive method name having parameters with descriptive variable names, 80 characters won't be enough. - Jon Limjap
Well I do have methods with descriptive names - I don't see that thes ehave to be long though, given the class they are members of provides context. My own standard is to enforce a right margin at 78 characters. - anon
(3) I guess you haven't tried TDD, or DDD for that matter, yet ;) - Jon Limjap
(7) @Jon Limjap: Simply break up such lines into multiple lines. The compiler generally doesn't care, but human readers (the most important when maintainability and cost-of-code are concerned) usually will. - peSHIr
(3) That's actually how I came up with 110 columns, I looked at a few books and made an average, then rounded down. Books on programming tend to be a bit 'wider' than others as far as columns go. - Tim Post
It also depends on a language. On an average word length to be more specific. Russian books for example tend to have slighlty wider collumn. - akalenuk
The two books I had to hand, both C++ classics in English, both had line lengths around 65 characters. - anon
@Neil - yes, I believe the number is 66-70, depending on the publisher. - ldigas
(5) Donald Knuth says page text width is based on average words not average characters. And he explains what makes the lines readable and not distractingly short or long. Code on the other hand is mostly for the compiler and your fellows. Find out if your fellows use an 80column terminal, if not, adjust accordingly. - dlamblin
(3) The problem with this reasoning is that code restricted to the layout of the pages of a book often isn't very readable at all. Code is not your normal flowing text which you can pour into a layout with very few additional structures (paragraphs, chapters, etc.), code is all about structures. - sbi
1
[+36] [2009-04-14 09:54:59] Agnel Kurian

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.


(27) Viewing files side-by-side is a huge advantage of the 80-character limit. - Matthew
+1 - the only limit I place on my personal projects is that I can have two windows side by side and not wrap lines. - Skilldrick
(3) And most of the time seeing 3 files side by side is also very useful. You can compare version A, Version B and their common ancestor. - Xavier T.
@Xavier: At that point you're better off using a proper diff/merge tool, but that's not the only time when you need side-by-side windows. (Having more and bigger monitors helps too; that lets you get even more on the screen at once...) - Donal Fellows
2
[+16] [2009-04-14 09:30:09] Richard

While the physical limitations of green screen terminals are largely gone, it 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.


(3) He's also very likely to know where you work. You can't escape! - Donal Fellows
(3) And he wears you shirt, plays with your kids, sleeps with your wife... I mean you are the most likely to consume your code :-) - Luc M
3
[+11] [2009-04-14 09:38:54] Chris Huang-Leaver

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


4
[+10] [2009-04-14 09:28:26] Steve Haigh

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?


5
[+10] [2009-04-14 09:36:01] User

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.


(1) I often grab my netbook (1024 pixels wide) and review some code while on a go / in a coffee shop. People STILL use lower resolutions then fullHD, really. - kender
(2) I haven't seen a notebook with a res lower than 1280x800 for ages. A for the netbooks, well, you may of course try to use them but in my opinion they are quite useless toys. - User
(4) I gotta strongly disagree. There's a diffrence in carrying a 1kg "toy" vs 4kgs "super-duper notebook" if you're on the go. Doesn't bother me much if I'm just traveling between an airport and hotel, but in any other case, light netbook is a win for me. Other thing is, you often don't want only your code on a screen, sometimes the browser window (if your application is webby, or you're looking at bugs database, or browsing docs). Sometimes you want your screen divided between code editor and something else. - kender
(1) I just read today something about 30% of netbooks being return back to stores because the sellers exaggerate their functionality and position them wrongly in general. - User
doYouVariableNamesReallyLookLikeThis? thisIsNotReadableAtAll, itMightEvenBeASignThatYouAreBreakingTheLiskovPrincipleInOop. - phresnel
@User, these days Netbooks are very different. Considered coding on a Macbook Air? - Thorbjørn Ravn Andersen
6
[+10] [2009-04-14 09:52:36] mouviciel

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.


(4) So are you advocating always writing for the edge case of blog posts, (to which this question seems to be leaning, ie general practice), or suggesting that people should reformat code when blogging/posting? - Simeon Pilgrim
(1) The least would be to reformat when blogging/posting. Moreover, I think it doesn't hurt if this becomes a day to day practice. Nevertheless I am not an extremist. On this kind of subjects, consistency among the team is more important than possibility of being published. - mouviciel
@mouvicial: well said - dfa
@dfa: agreed, well said mouvicial - Simeon Pilgrim
7
[+10] [2009-07-31 21:19:02] Alistair Knock

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.


(3) And yes, I know there is a horizontal scrollbar in the third version - boo hoo, it's a display problem, not a coding problem. - Alistair Knock
(11) Even if you ignore the 80-character limit, the second version is just way more readable here (although personally I would put FROM and TheTableOfMythicalBeasts on the same line). - Matthew
(1) I think you're on to something really cool here! In the context of source code, the user agent formatting approach could apply to more than just line wrapping. You're making me realize that there is still a lot of room for improvements to editors. - binarycoder
(1) This problem is in the language itself; it would be better to use a language that allows multi-line strings without silly "_" trickery. - Matti Virkkunen
Yes, VBA is crazy in this respect, but I don't think it's that language-specific. My point is that in the case of line breaks, it shouldn't fall on the programmer to forcibly govern the presentation; the editor should do this based on the user's preference and on the language's aesthetic. - Alistair Knock
Rather than ending with a space, I end with & vbNewline & _, which makes it a lot easier to notice and also makes the code easier to read, in the case of VBScript, if you need to output it for debugging purposes. Of course, VBA/VBScript are evil so under no circumstances should you /choose/ to use either nor use them to defend your practices. :P - bamccaig
It's not a new idea, but unfortunately there aren't any widespread implementations. It boils down to "why write something as structured as code in a medium as unstructured as text?". And yes, I totally can't wait till we get rid of text in programming, and with it every code formatting war ever fought on the internet. Just imagine the bliss of other people's code being displayed in a way that's tailored to your personal taste. Wouldn't that be neat. - romkyns
But sir! We are doing this one small task... for each other! It's not to please some tyrannical third party's demands; there is no need for a rebellion here. Even if text editors become perfect, or some non-text form of programming becomes available, we can't know for certain that we or a friend won't occasionally need to edit our programs the old way. When I run a program and it outputs text that my terminal emulator doesn't wrap, I have to resize and rerun... possibly more than once! Please for my sake, for the sake of your peers, slow down and take the time to format your code nicely! (ToT) - Ziggy
8
[+7] [2010-03-05 23:56:49] Catskul

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 three levels of four 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...


If lines are too long it is time to start having local variables with shorter names instead of picking out fields in image0 and image1. - Thorbjørn Ravn Andersen
In this case would you suggest saving image0.height() into int image0height? It seems to me that would save about 3 characters. You could compress it into img0h or some such, but that violates preposed symbol naming convention. - Catskul
no into height0, width0 and depth0 respectively. Perhaps even h0, w0, and d0 if really pressed. - Thorbjørn Ravn Andersen
item0->setConfiguration( image0.getDetails() ); or item0->setConfiguration( getDetails(image0) ); are two possibilities. Package up the data that goes together into a class. - Sean
@Sean that would of course work, but beside the issue. This is not meant to be a specific case to be solved, but rather an illustration of a more general idea. - Catskul
Indeed, but I think cases where more than 80 chars are needed may be pointing to other issues. In this case the parameter lists could be made shorter. For me that is a general strategy - keeping to 80 chars by refactoring like above benefits code in more than just shortening the lines. Reducing indentations by calling a sub method is another example; shorter lines and less complexity (I don't like wrapping lines if I can help it). - Sean
9
[+5] [2009-04-14 10:06:58] Anteru

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.


10
[+5] [2009-07-31 21:05:34] Peter Mortensen

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 [1] (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.

[1] http://www.python.org/dev/peps/pep-0008/

11
[+5] [2011-09-03 12:30:38] gnat

I miss good old 80-char line length limit [1] every time I do code review...

  • ...I miss it every time I look at side by side diff like that: two-sided diff when lines are too long

Yeah I have two large displays. Yeah I can stretch the diff tool window on both displays so that I can see 2x120 or even 2x160 diff. But somehow, it still sucks. Just sucks.

[1] http://www.oracle.com/technetwork/java/codeconventions-136091.html#313

12
[+3] [2011-01-20 23:29:40] Webveloper

Unless you're stuck with a console that limits you, I think 80 is outdated. (That number originated with punch cards!) Even with a console, you can probably set it to 132, the next standard terminal size.

With Visual Studio, I've decided to use 142. When printing code in landscape orientation with line numbers visible, that's how many columns VS prints on an 8.5x11 piece of paper without wrapping. (I use 10pt Consolas - I don't know if font size applies to printing.) With tool panes open on both sides of VS with a 1680-pixel screen, I can see 150 columns of code, so 142 works well there.

Using the Productivity Power Tools [1] extension for Visual Studio, I set guidelines at 80, 132, and 142. (Note that the "Col ##" indicator in the lower-right of VS is 1-based, so to set a guideline at 132, put the cursor where the indicator says 133.)

I'll aim for 132, let it slide to 142, and if there's a choice between readability and column limit, readability wins. I only use the 80-column guideline for CSS, but even then, image URLs that exceed the limit can't be wrapped.

[1] http://visualstudiogallery.msdn.microsoft.com/en-us/d0d33361-18e2-46c0-8ff2-4adea1e34fef

+1 for mentioning the origin of the 80-character limit: punch cards. - NovaJoe
13
[+2] [2011-02-03 09:09:52] andrea

80 columns started with typesetting and printing. It has nothing to do with resolution of screens or screen size. 80 columns is based on the function of the human eye and readability. Much beyond 80 columns and the eye tends to not follow on one line but drop to the next, especially in blocks of text.


14
[+1] [2009-04-14 09:28:04] Gamecat

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.


15
[+1] [2009-04-14 10:38:32] AnnaR

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.


16
[+1] [2011-06-13 00:49:49] Lightness Races in Orbit

If nothing else, if your line of code is longer than 80 characters, something is probably wrong.

Terminals notwithstanding, that's not terse code and as such it's neither quickly legible nor properly maintainable.


17
[+1] [2011-06-20 02:36:55] Sjur Julin

I don't think readability has to do only with length/visibility of statements, but as much about program flow. Isn't it easier to read a program when lines are tightly stacked? Usually I care more what the program flow is than each individual statement. Most source files are longer than the screen, so the case could be made to use multiple statements on each line to fit as much program as possible on screen. However as someone mentioned, the editor could right-align wrapped text in case someone really needs to see the end of the line.

I prefer tight code in a small type, on black background, and when printed it should be possible to fit more than eighty chars on a line, and more than one function on each page. Often the most proper formatting contains the least readable code. I use by two-space indents, wide/multiple statements on a line, BLACK background so help me GOD (incredible how white bg survived the crt). If people are so stingy on screen real-estate, how come every developing environment is filled with sidebars, icons and stuff, and every file manager gui uses big icons, big fonts, side panes, alternating grey/white lines, multiple useless toolbars?

Oh, and unix style curly braces. They save me lines.


18
[0] [2009-04-14 09:30:49] mezoid

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.


19
[0] [2009-04-14 09:32:59] Jon Limjap

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.


(11) AssignNumberToCustomerAndSetOrderStatus is a horrible name. Method names should never use the word "and." - Kevin Panko
(2) Indeed... it means it's doing more than one thing. Good call Kevin. ;) - Jon Limjap
20
[0] [2009-04-14 09:42:01] Stefano Ricciardi

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.


21
[0] [2010-02-24 17:58:15] Pedro Palhoto

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.


22
[0] [2011-03-29 21:08:32] Dave

I code for readability. You can't read what you can't see. An 80 column limit is a little strict unless you're dealing with a language / platform that won't handle it. Last I checked, IBM's FORTRAN languages were still enforcing 72 columns. Admittedly it has been a while, but they didn't change their methods in the 20+ years I dealt with them. I don't expect them to change in the last few.


23
[-1] [2010-05-17 14:20:39] MyjimBy

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()              );

24
[-1] [2012-03-20 09:20:21] Larswad

OK, I know this is a very subjective matter, but I think that the argument "readability" for 80 columns is quite debatable. I think the code becomes quite unreadable if it is chopped up every 10-60 characters (because that's what usually happens when you have descriptive variable names).

I believe humans are far more used to reading from left to right (or right to left depending on where you live for that matter) rather left-right DOWN left right DOWN left right and so on. I find it actually very hard to read code being chopped up like that and I think it is also aesthetically plain ugly.

By this, I don't mean we should write horribly wrong lines, one should use common sense of course. It should be discussed in each project, bring it up as early as possible to avoid hard discussions later. Personally I say, use tools and editor that has evolved beyond the 1980s and 1990s. Sticking to handicapped tools for some nostalgic reason is just not good enough.


25