We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

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.
–
user1249Aug 14 '11 at 19:33

In what context? If you are asking in a specific programming context, I would vote to reopen.
–
NickCAug 14 '11 at 21:29

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.

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.
–
musiphilAug 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.
–
AllanAug 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 CampbellAug 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, 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.
–
greyfadeSep 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 CampbellSep 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 FellowsMay 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..
–
RossMar 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.

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 PateSep 9 '10 at 16:13

1

Ahh, that's just some pseudo-code I wrote. But I think C requires it.
–
Cesar CanassaSep 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 PateSep 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.
–
starblueOct 17 '10 at 14:03

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 PateSep 11 '10 at 13:58

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.

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.

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.