Is there a valid reason for enforcing a maximum width of 80 characters in a code file, this day and age?

Seriously. On a 22" monitor, it only covers maybe a quarter of the screen. I need some ammo to axe down this rule.

---

I'm not saying that there shouldn't be a limit; I'm just saying, 80 characters is very small.

I think the practice of keeping code to 80 (or 79) columns was originally created to support people editing code on 80-column dumb terminals or on 80-column printouts. Those requirement have mostly gone away now, but there are still valid reasons to keep the 80 column rule:

• To avoid wrapping when copying code into email, web pages, and books.
• To view multiple source windows side-by-side or using a side-by-side diff viewer.
• To improve readability. Narrow code can be read quickly without having to scan your eyes from side to side.

I think the last point is the most important. Though displays have grown in size and resolution in the last few years, eyes haven't.

The origin of 80-column text formatting is earlier than 80-column terminals -- the IBM punch card dates back to 1928, and its legacy to paper tapes in 1725! This is reminiscent of the (apocryphal) story that the US railway gauge was determined by the width of chariot wheels in Roman Britain.

I sometimes find it a bit constricting, but it makes sense to have some standard limit, so 80 columns it is.

Here's the same topic covered by Slashdot.

And here's an old-school Fortran Statement:

80 characters is a ridiculous limit these days. Split your code lines where it makes sense, not according to any arbitrary character limit.

You should just do it for the sake of everyone who doesn't have a 22 inch widescreen monitor. Personally, I work on a 17 inch 4:3 monitor, and I find that more than sufficiently wide. However, I also have 3 of those monitors, so I still have lots of usable screen space.

Not only that, but the human eye actually has problems reading text if the lines are too long. It's too easy to get lost in which line you are on. Newspapers are 17 inches across (or somethign like that), but you don't see them writing all the way across the page, same goes for magazines and other printed items. It's actually easier to read if you keep the columns narrow.

When you have a sequence of statements that repeat with minor variations it can be easier to see the similarities and differences if the they are grouped into lines so that the differences align vertically.

I'd argue that the following is much more readable than it would have been if I'd split it over multiple lines:

switch(Type) {
case External_BL:	mpstrd["X"] = ptDig1.x - RadialClrX;	mpstrd["Y"] = ptDig1.y - RadialClrY;	break;
case External_BR:	mpstrd["X"] = ptDig1.x + RadialClrX;	mpstrd["Y"] = ptDig1.y - RadialClrY;	break;
case External_TR:	mpstrd["X"] = ptDig1.x + RadialClrX;	mpstrd["Y"] = ptDig1.y + RadialClrY;	break;
case External_TL:	mpstrd["X"] = ptDig1.x - RadialClrX;	mpstrd["Y"] = ptDig1.y + RadialClrY;	break;
case Internal_BL:	mpstrd["X"] = ptDig1.x + RadialClrX;	mpstrd["Y"] = ptDig1.y + RadialClrY;	break;
case Internal_BR:	mpstrd["X"] = ptDig1.x - RadialClrX;	mpstrd["Y"] = ptDig1.y + RadialClrY;	break;
case Internal_TR:	mpstrd["X"] = ptDig1.x - RadialClrX;	mpstrd["Y"] = ptDig1.y - RadialClrY;	break;
case Internal_TL:	mpstrd["X"] = ptDig1.x + RadialClrX;	mpstrd["Y"] = ptDig1.y - RadialClrY;	break;
}

Update: In the comment's it's been suggested that this would be a more succinct way of doing the above:

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY; 

although it now fits in 80 columns I think my point still stands and I just picked a bad example. It does still demonstrate that placing multiple statements on a line can improve readability.

Printing a monospaced font at default sizes is (on A4 paper) 80 columns by 66 lines.

I use the the advantage of bigger screens to have multiple pieces of code next to eachother.

You won't get any ammo from me. In fact, I'd hate to see it changed since in emergencies I still see rare cases where I need to change code from a text-console.

Super-long lines are harder to read. Just because you can get 300 characters across on your monitor doesn't mean you should make the lines that long. 300 characters is also way too complex for a statement unless you have no choice (a call that needs a whole bunch of parameters.)

I use 80 characters as a general rule but I'll go beyond that if enforcing it would mean putting a line break in an undesirable location.

The only thing I enforce to stay within 80 chars is my commenting.

Personally...I'm devoting all my brain power (what little there is) to coding right, it's a pain to have to go back and break everything up at the 80 char limit when I could be spending my time on the next function. Yes, Resharper could do it for me I suppose but then it freaks me out a little that a 3rd party product is making decisions on my code layout and changes it ("Please don't break my code into two lines HAL. HAL?").

That said, I do work on a fairly small team and all of our monitors are fairly large so worrying about what bothers my fellow programmers isn't a huge concern as far as that goes.

Seems though some languages encourage longer lines of code for the sake of more bang for the buck (short hand if then statements).

The other answers already summed things up nicely, but it is also worth considering when you might want to copy & paste some code into an email, or if not code then a diff.

That's a time when having a "max width" is useful.

I have two 20" 1600x1200 monitors and I stick to 80 columns because it lets me display multiple text editor windows side-by-side. Using the '6x13' font (the trad. xterm font) 80 columns take up 480 pixels plus the scrollbar and window borders. This allows one to have three windows of this type on a 1600x1200 monitor. On windows the Lucida Console font won't quite do this (the minimun usable size is 7 pixels wide) but a 1280x1024 monitor will display two columns and a 1920x1200 monitor such as an HP LP2465 will display 3. It will also leave a bit of room at the side for the various explorer, properties and other windows from Visual Studio.

Additionally very long lines of text are hard to read. For text the optimum is 66 characters. There is a point where excessively long identifiers start to be counterproductive because they make it hard to lay out code coherently. Good layout and indentation provides visual cues as to the code structure and some languages (Python comes to mind) use indentation explicitly for this.

However, The standard class libraries for Java and .Net tend to have a preponderance of very long identifiers so one cannot necessarily guarantee to be able to do this. In this case, laying out code with line-breaks still helps to make the structure explicit.

Note that you can get windows versions of '6x13' fonts Here.

In the Linux coding standard, not only do they keep the 80 character limit, but they also use 8 space indentation.

Part of the reasoning is that if you ever reach the right margin, you should consider moving an indentation level into a separate function.

This will make clearer code because regardless of indentation lengths, it is harder to read code with many nested control structures.

People say long lines of code tend to be complex. Consider a simple Java class:

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

This is 94 characters long and the class name is quite short (by GWT standards). It would be difficult to read on 2 lines and it is very readable on one line. Being pragmatic about it and thus allowing "backwards compatibility", I'd say 100 characters is the right width.

You are not the only person who is going to maintain your code.

The next person who does might have a 17" screen or might need large fonts to read the text. The limit has to be somewhere and 80 chars is the convention due to previous screen limitations. Can you think of any new standard (120) and why it is a good idea to use that other then "that's what fits on my monitor at Xpt font?"

Remember, there are always exceptions to every rule so it you have a particular line or block of code that makes sense to be more than 80 chars then be a rebel.

But take the time first to think "is this code really that bad that it can not live within 80 chars?"

I've widened my code out to 100 characters which fits comfortably in less than half my screen on my Macbook. 120 characters is probably the limit before lines start to get too long and complex. You don't want to get too wide else you encourage compound statements and deeply nested control structures.

The right margin is nature's way of telling you to perform an extra method refactoring.

I wonder if this might cause more problems in this day and age. Remember that in C (and possibly other languages) there are rules for how long a function name can be. Therefore, you often see very hard-to-understand names in C code. The good thing is that they don't use a lot of space. But every time I look at code in some language like C# or Java the method names are often very long, which makes it close to impossible to keep your code at a 80 characters length. I don't think 80 characters are valid today, unless you need to be able to print the code, etc.

As the author of coding guidelines for my employer I have upped the line length from 80 to 132. Why this value? Well, like others pointed out, 80 is the length of many old hardware terminals. And 132 is as well! It's the line width when terminals are in wide mode. Any printer could also make hardcopies in wide mode with a condensed font.

The reason for not staying at 80 is that I rather

• prefer longer names with a meaning for identifiers
• not bother with typedefs for structs and enums in C (they are BAD, they HIDE useful information! Ask Peter van der Linden in "Deep C Secrets" if you don't believe it), so the code has more struct FOO func(struct BAR *aWhatever, ...) than code of typedef fanatics.

and under these rules just 80 chars/line cause ugly line wraps more often than my eyes deem acceptable (mostly in prototypes and function definitions).

As others have said, I think it's best for (1) printing and (2) displaying multiple files side by side vertically.

I like to limit my width to 100 chars or so to allow two SxS editors on a widescreen monitor. I don't think that there is any good reason for a limit of exactly 80 chars anymore.

There's already a lot of good answers to this, but it's worth mentioning that in your IDE you might have a list of files on the left, and a list of functions on the right (or any other configuration).

You're code is just one part of the environment.

Use proportional fonts.

I'm serious. I can usually get the equivalence of 100-120 characters in a line without sacrificing readability or printability. In fact it's even easier to read with a good font (e.g., Verdana) and syntax coloring. It looks a little strange for a few days, but you quickly get used to it.

I thing not enforcing 80 characters means eventually word wrapping.
IMO, any length chosen for a max-width line is not always appropriate and word wrapping should be a possible answer.
And that is not as easy as it sound.

It is implemented in jedit
_{(source: jedit.org)} which offers word wrap

But it is bitterly missed in eclipse from a looong time ! (since 2003 in fact), mainly because a word wrap for text editor involves:

• Wrapped line information is for the text viewer, code navigation, vertical rulers.

• Unwrapped line information is required for functionalities like goto line, line numbering ruler column, current line highlight, saving file.

I try to keep things down near 80 characters for a simple reason: too much more than that means my code is becoming too complicated. Overly verbose property/method names, class names, etc. cause as much harm as terse ones.

I'm primarily a Python coder, so this produces two sets of limitations:

1. Don't write long lines of code
2. Don't indent too much

When you start to reach two or three levels of indentation, your logic gets confusing. If you can't keep a single block on the same page, your code is getting too complicated and tricky to remember. If you can't keep a single line within 80 characters, your line is getting overly complicated.

It's easy in Python to write relatively concise code (see codegolf) at the expense of readability, but it's even easier to write verbose code at the expense of readability. Helper methods are not a bad thing, nor are helper classes. Excessive abstraction can be a problem, but that's another challenge of programming.

When in doubt in a language like C write helper functions and inline them if you don't want the overhead of calling out to another function and jumping back. In most cases, the compiler will handle things intelligently for you.

I'm diffing side-by-side all day long and I don't have a freakin' 22 inch monitor. I don't know if I ever will. This, of course, is of little interest to write-only programmers enjoying arrow-coding and 300-char lines.

I actually follow a similar rule for my own code but only because of printing code to an A4 page - 80 columns is about the right width for my desired font size.

But that's personal preference and probably not what you were after (since you want ammo to go the other way).

What don't you question the reasoning behind the limit - seriously, if no-one can come up with a good reason why it's so, you have a good case for having it removed from your coding standards.

Yes, because even in this day and age, some of us are coding on terminals (ok, mostly terminal emulators), where the display can only display 80 chars. So, at least for the coding I do, I really appreciate the 80 char rule.

I force my students to squeeze into 80 columns so I can print out their code and mark it up.

And about 17 years ago I let my own code expand to 88 columns, because I started doing everything using Noweb and 88 columns is what fits in a nicely printed document using TeX.

I indent by only two spaces, but the extra room is wonderful.

I still think that the limit isn't limited on the visual part. Sure, the monitors and resolutions are big enough to show even more characters in one line nowadays, but does it increase the readability?

If the limit is really enforced it's also a good reason to re-think the code and not to put everything into one line. It's the same with indentation - if you need to much levels your code needs to be re-thought.

Breaking at 80 characters is something you do while coding, not afterwards. Same with comments, of course. Most editors can assist you in seeing where the 80-characters limit is.

(This may be a little OT, but in Eclipse there is an option which formats the code when you save it (according to whatever rules you want). This is a little freaky at first, but after a while you start to accept that the formatting is no more in your hands than the generated code is.)

If we had one of these, we wouldn't be having this discussion! ;-)

But seriously the issues that people have raised in their answers are quite legitimate. However the original poster was not arguing against a limit, merely that 80 columns is too few.

The issue of emailing code snippets has some merit. But considering the evil things that most email clients do to pre-formatted text I think that line wrapping is only one of your problems.

As for printing I usually find that 100 character lines will very comfortably fit onto a printed page.

I try and keep my lines below 80 columns. The strongest reason is that i often find myself using grep and less to browse my code when working at the command-line. I really don't like how terminals are breaking long source lines (they after all aren't made for that job). Another reason is that i find it looks better if everything fits into the line and isn't broken by the editor. For example having parameters of long function calls nicely aligned below each other and similar stuff.

We did a survey recently. Almost everyone uses vim inside an gnome-terminal, and if we do a vertical split the column count is 78 as standard font size and screen resolution 1280x1024.

So we all agreed to a coding standard with a column count of (around) 75 characters. It's ok.