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

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

+7  A: 

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.

+1  A: 

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.

I'm pretty sure it's from the days when text mode screens were 80 characters wide.
+23  A: 

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.

Not when you add indenting into the mix. If you use 4 spaces per indent, and you're in something like, namespace->class->method->if->for, that's 1/5th of your space blown.
You could always set the rule at 80 chars from the indent. That way the eye can easily follow it.
Vincent McNabb
Sometimes, (but not always) I wish .Net had automatic namespacing so that your didn't have to define the namespace in the file. That seriously messes with the alignment of your code. if you want nested namespaces, you have really big problems.
However, reading prose is not the same as reading code.
+5  A: 

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.

Steve Kemp
+1  A: 
+3  A: 

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 will live with 80 chars when I can have 2spc tabstops.Better yet, actually use tabs for indentation, the requirement is when tabsize = 2, fits in 80 columns, use 4 most of the time for better readability. That way when you really have to choke down to 80 columns you can, but at a price.
+5  A: 

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.

Loren Pechtel
There are studies that show that people can read and follow x amount of characters/words, before they loose track. I am thinking 80 is in there somewhere. I don't have any sources to back that up though.
+3  A: 

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

Thomas Owens
+4  A: 

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.

Thank you for saying this! Big monitors are all the *more* reason for the 80 line limit, so you can fit more windows side-by-side. Not to mention that it's nice to be able to print source code (on paper) sometimes. Or paste snippets into other documents.
+104  A: 

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.

Will Harris
You don't need eyes with higher resolution, or simply "bigger eyes", to read long lines. ;) I doubt long lines even make code harder to scan, unless each line is significantly long (100+ chars).
They may have "largely gone away", but not entirely. I tend to work with two different setups: 1) in an ssh window connected to a remote machine. which is 80 characters wide by default. and 2) In Visual Studio, with two panels side-by-side so I can see header and cpp file at the same time.
@steffenj: Actually, books tend to shoot for about 66 characters per line (although this varies somewhat depending on other parameters) because longer lines *do* make reading more difficult. Maximum _code_ line length could be argued, but 80 is convenient for historical and practical reasons.
Steve S
The problem is by forcing people to keep line lengths short they tend to use less meaningfull names..
Ian Ringrose
I find the remarks about readability quite interesting, because the thing I really hate about printed programming articles/books/... is, that the short lines which are used for the code examples are so extremely hard to read. It can make a lot of sense to move something to a new line, but the grouping should occur logically, dissecting the expression recursively, not because the output device accidentally reached its limitation. IOW, I find that devices which impose such narrow restrictions are not well suited to display code.
Chris Lercher
+16  A: 

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


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.

+27  A: 
+5  A: 

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).

Enjoyed your hal ref :)
+1  A: 

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.

How about reading code with many function calls? Surely there's a compromise between these two approaches...
Zsolt Török
+1  A: 

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.

Jamie Eisenhart

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.)

+9  A: 

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.

Sam Hasler
By saying that there are only small differences from line to line, you also say, that there is a lot of redundant code. Removing some of that could significantly decrease the number of columns and still be vertically aligned.
@mxp: agreed. If there's a more concise way of writing the above I'd be interested to see it.
Sam Hasler
I agree with the general idea, but the example... What about this: switch(...) { case ...BL: dxDir = - 1; dyDir = - 1; break; case ...BR: dxDir = + 1; dyDir = - 1; break; ... } ...["X"] = pt1.x + dxDir * Rad...X; ...["Y"] = pt1.y + dyDir * Rad...Y;
Oops... Code sample in comments looks ugly. But I hope you got the idea. :-)
@sam: The idea is that if you seen such long lines as in your original example it's probably should be re-factored to make a code more efficient. Long lines usually mean bad code (not always just usually)
The fact that I need to scroll the first of the two examples horizontally kind of proves the pint about shorter lines being better :-)

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.

Andrew Edgecombe
+1  A: 

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.

Dan Udey
+1  A: 

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.

+9  A: 

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


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.

+1  A: 

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.

+1  A: 

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.


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 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.

Johannes Schaub - litb

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.

Norman Ramsey

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.

+2  A: 

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.