on a widescreen monitor one can easily see more than 80 characters at a time, without scrollbars. even linus torvalds sees the 80 character limit as outdated.

so, is the 80 character limit still relevant in times of widescreen monitors?

  • 1
    There is a very good reason to keep lines short in e.g. Eclipse. This allows you to print your programs on a normal printer in a readable font without line wrapping. – user1249 Aug 14 '11 at 19:33
  • In what context? If you are asking in a specific programming context, I would vote to reopen. – Nicole Aug 14 '11 at 21:29
  • 1
    The 80 Character Limit – hakre Jun 5 '12 at 7:22
  • Visual Studio's word wrap is broken, so most users have it off. Instead, they put in line breaks by hand. This looks terrible for anyone with a different screen width. visualstudio.uservoice.com/forums/121579-visual-studio/… – Colonel Panic Mar 13 '13 at 14:31

11 Answers 11


There are several reasons to still adhere to an 80 character limit (or, a 74 character limit is even better; it allows for the code to remain fewer than 80 columns even when diff markers and email quoting is added, if you do code review on mailing lists).

Even in the era of widescreen monitors, I like to have several windows open side by side, showing different parts of the code. For instance, I usually have a web browser and email open on one screen, and two files and a terminal open side by side on a second monitor. If you have lines that run over 80 columns, you need to deal with the editor wrapping the lines (which is ugly and makes the code harder to navigate around), or widen you windows such that you can't fit as many on screen at once.

Even if you don't usually edit this way, if you ever use a side-by-side diff tool, you will appreciate files with reasonable line lengths which will make your diff easier to view.

There's also an issue of code density. I like to have a lot of context when reading code. It is much, much quicker to glance up and down a window than it is to scroll. If you have very long lines, you also tend to have lines that vary in length a lot, leading to a lot of wasted screen real estate and being able to fit less code on screen at a given time overall.

And finally, if you have very long lines, then that generally means that you have very complicated lines, deep indendation, or that you have very long identifiers. All of these can be a problem. Complicated lines are probably doing too much; if you can break it down into several simpler lines, you probably should. Deep indentation means that you're probably nesting too many loops and conditionals, which can make your code flow confusing; considering refactoring into several functions. And if your identifiers are too long, it can make reading your code very difficult. People generally recognize words as individual units; they don't read every character one by one, but look at the overall shape of the word. Long identifiers are harder to distinguish this way, and usually if they are that long, they contain redundant or repetitive information.

Now, while it's still good practice to keep code below 80 columns, this isn't one of those rules that needs to be followed religiously, contorting yourself to make some line fit when it just doesn't. I suggest that you try to keep all of your code under 80 columns, but when it just doesn't fit, don't worry about it too much.

  • 3
    Agreed. However, long identifiers are sometimes encouraged (by coding guidelines such as "use meaningful names" or "avoid cryptic abbreviations") or necessary (such as std::vector<...>::const_iterator), though in the latter case, things can usually be alleviated by typedefs. – musiphil Aug 16 '13 at 1:40
  • Great reasons. I'm not sure that the exact line length matters, as long as your team (or mailing list?) agrees to it. Personally, I go with Uncle Bob's suggestion to never exceed 120 characters. – Allan Aug 20 '13 at 23:31
  • 1
    @musiphil Yeah, that's why I included the last paragraph. I've run into lines in C++ where I simply could not fit the class name, method name and return type onto one 80 column line when declaring the method. Rather than doing some really weird line-breaking, it's better to just break the 80 column (or 100 column) rule for that one line. – Brian Campbell Aug 21 '13 at 15:45

If I keep my lines to less than about 100 characters, I can have two editor windows side-by-side on a widescreen monitor. It's very useful to have both the class header file and implementation both visible at the same time, or have code on one side that calls into the code on the other. And, if I keep the lines short, I don't need a horizontal scrollbar on my editor windows, which gives me more vertical space.

80 characters may be outdated, but there's some merit in keeping things within reason.

  • 1
    +1, I frequently open multiple source files side-by-side in Vim or other editors. With a sufficiently small font and a reasonably narrow right-margin, I can very quickly get a good overview of the project and even open lots of documentation. – greyfade Sep 3 '10 at 16:05
  • 4
    80 characters is still relevant because many people default to having their terminals and editors that wide; thus, if you limit yourself to 80, you will be friendly towards those folks, as opposed to requiring them to rearrange all of their windows or deal with line wrapping or horizontal scrolling. – Brian Campbell Sep 10 '10 at 14:55
  • 1
    80 chars is still reasonable; going longer than that encourages over-nested code (instead of refactoring!) and having many windows side by side is exceptionally useful. Adding another monitor just increases the number of windows you can see at once! – Donal Fellows May 13 '11 at 19:36
  • 1
    80 is friendly to VMS maybe. Forgive my new age thinking but we should extend the limit where possible and keep it where necessary.. – Ross Mar 26 '12 at 23:58

I don't think the monitor has anything to do with it - at least not anymore.

If you can't code a line in 80 characters, that's probably a sign of bad code anyway. Too complex expressions. Too deep indentation. etc. You should stop and rethink what you are doing.

But if you are sure that the code required more than 80 lines, then go ahead and do it. I think it's better to have a code that surpasses the 80 characters than adding idiomatic changes only to make it smaller.

I personally hate this kind of stuff:

ret = my_function(parameter1, \
                  parameter2, \
                  parameter3, parameter4);

Instead of simply:

ret = my_function(parameter1, parameter2, parameter3, parameter4);
  • 5
    Surely if line 3 in the first example isn't too long, line 2 can be combined into line 1, which makes it look much more readable. (What language requires escaped newlines within parentheses?) – Roger Pate Sep 9 '10 at 16:13
  • 1
    Ahh, that's just some pseudo-code I wrote. But I think C requires it. – Cesar Canassa Sep 10 '10 at 20:40
  • 4
    Only in multi-line macro definitions, which are (or should be) rare. It significantly affects choice of max line length (maintaining such backslashes isn't fun), so I'm curious why you show it. Seems to be a straw man? – Roger Pate Sep 11 '10 at 13:54
  • 2
    If I go to the trouble of breaking a line in a function call, I'd put each parameter on its own line, indented by one level. – starblue Oct 17 '10 at 14:03

To coding?

Certainly yes. Normal human been can't read well too wide. With few columns you move your eyes less, you focus better and delay the tiredness. It's a minimum gain but an important one.

  • 3
    While I feel code is very different from prose, it is tiring to read code that periodically (i.e. prose would generally be much more consistent) stretches lines out to 120+ columns. – Roger Pate Sep 11 '10 at 13:58

Yes, there are reasons to limit code line length:

  1. Although our screens have gotten wide, sometimes you need to print out your code. If only for this reason.
  2. Diff-viewers often display lines with a vertical split - this becomes harder if the lines are as long as a wide screen would allow.

Having said that, 80 is a bit too little. But, still, some limitation is probably a good idea as a design principle.

I would say that extra long lines shouldn't be disallowed, because occasionally they are necessary. But if most functions are only viewable on a 30" screen then the code has some issues.


It's arbitrary, but there is a non-arbitrary limit to what is easy to read. I find that super-wide columns of text are very hard to scan and read, regardless of if they are code or prose. Further, as a lot of other answers have pointed out, it's not like this code is going to be the only thing up on your screen. It's great to have two or more windows of code up at the same time, and have them fit on one wide screen monitor.


It is probably not relevant to choose exactly a 80 character limit; what would change if the limit is 85, for example?

It's true that monitors used nowadays have higher resolutions, but in a text editor/IDE, not all the space is taken from the text view; in the editor I use shows to the left side the list of the files included in the project.

The resolution used in a netbook, or a notebook is not the same used in monitors; it probably makes sense to use a character limit that doesn't create "problems" to anybody.

  • 5
    80 characters was the hard limit of the number of columns on punch card! – ChrisF Sep 9 '10 at 13:40
  • 5
    It doesn't matter what the standard is, but if everybody works to the same standard then it makes lives easier. – Skilldrick Sep 21 '10 at 8:27

It really depends on the development environment.

For example, in a large corporation with thousands of developers, there are probably hundreds of people who will, over the course of a product's lifetime, have to look at some portion of it's code. With that many people, there's bound to be a few who, for whatever reason (older hardware, netbooks, etc) are operating at 800x600 or smaller. There's some value to accommodating them.

At my 25-person company, though, I say screw it. We're all using dual modern monitors at the maximum resolution- 120-140 or so is the informal guideline.


Having some limit certainly makes sense. But 80 character limit is too constraining. I prefer something like 96 character limit. It's wide enough for most of the code I have to deal with and it's narrow enough so that two files can be put side by side for diff'ing (on a wide screen).

I believe code readability trumps all other concerns. And with 96 characters per line code can be made much more readable than with 80.

I don't buy the argument that most people set their terminals to 80 characters wide, no that printers have to wrap lines longer than 80 characters. It's not a hard limit as it used to be in the (distant) past. You can easily set the terminal and the printer width to 100 characters.


No, it's no longer relevant:

  • Most fonts used in applications and on the web aren't fixed-width anyway. In other words, 80 characters != 80 characters.
  • As you said, screen widths have changed - 80 characters is not a sensible boundary.

80 characters was really a guideline for fixed-width fonts in a console environment.

Of course, if you're still using a fixed-width font in a console environment... then sure, 80 characters is sensible :)

  • 3
    I'm pretty sure he was referring to the use of an 80-character limit in source code, which is almost universally displayed in monospaced fonts. – Fishtoaster Sep 3 '10 at 1:51
  • 1
    Hmm... in that case... still no, but for other reasons :) – Damovisa Sep 3 '10 at 3:03
  • 1
    80 characters was the hard limit of the number of columns on punch card! – ChrisF Sep 9 '10 at 13:39

If you use an editor in a GUI, then the 80 characters per line is irrelevant, since most decent editors - for example Notepad++ - have a button to toggle line wrap. With that, it should not be a problem, even when viewing the code in a thin window.

Not the answer you're looking for? Browse other questions tagged or ask your own question.