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

Question

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.

Solution 1

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.

Solution 2

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:

Solution 3

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

Solution 4

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.

Solution 5

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.

View more solutions

Comments

[Till]

All answers pretty much state what I wanted to add. To give you a real life example - I have a x61s, the resolution is 1024x768. When I am on the road, I don't have my fancy monitor. Opening code in my IDE is a pain when it exceeds this rule.

[Admin]

possible duplicate of stackoverflow.com/questions/95575/…

[Ivan Black]

Even if you have a set of 3 monitors. This is not a reason to shaking head right to left and back. Forever. Ah-ha-ha. Actually the eye moves faster than head. Do you know about columns into newspapers? The reason of the width is the eye/head/man convenience.

[RBT]

Related post - Why is 80 characters the 'standard' limit for code width? & Studies on optimal code width?

[Israr]

Update 12/13/2021: Merged : The Linux kernel has officially deprecated its coding style that the length of lines of code comply with 80 columns as the "strong preferred limit".31-May-2020 git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/…

[TraumaPony]

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

[TraumaPony]

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.

[Vincent McNabb]

You could always set the rule at 80 chars from the indent. That way the eye can easily follow it.

[Till]

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.

[Kibbee]

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.

[steffenj]

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

[foraidt]

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.

[Smilediver]

@mxp: agreed. If there's a more concise way of writing the above I'd be interested to see it.

[Yarik]

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;

[Yarik]

Oops... Code sample in comments looks ugly. But I hope you got the idea. :-)

[Ilya]

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

[Enno]

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.

[Enno]

The fact that I need to scroll the first of the two examples horizontally kind of proves the pint about shorter lines being better :-)

[Atario]

However, reading prose is not the same as reading code.

[dreeves]

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.

[vpalmu]

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.

[Steve S]

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

[Zsolt Török]

How about reading code with many function calls? Surely there's a compromise between these two approaches...

[Ian Ringrose]

The problem is by forcing people to keep line lengths short they tend to use less meaningfull names..

[Chris Lercher]

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.

[Cheezmeister]

I'm with @Enno, a wider screen means room for two 80-column files, not one mostly-80-column-with-a-few-honkin-long-lines and an editor full of unused space :) It's also important that current editors do have the ability to scroll horizontally so if a line should be more than 80 characters long, it's perfectly safe to leave it so.

[Todd Chaffee]

+1 for newspapers, great example. @Atario, reading GOOD code is very much like reading prose.

[KOGI]

I don't understand the hate for scrolling? It's a common opinion, and I'm not saying it's wrong, I just don't understand it. Especially if you're in a code editor, you don't even need to move your hands off the keyboard to get to the mouse -- just (ctrl+)arrow over or hit end

[KOGI]

Yeah, I think really, it's not about keeping the lines short so much as about keeping the lines clean/concise/readable/understandable.

[Raymond]

Quibble re Narrow code can be read quickly ... sometimes however I like to trade a bit of tennis viewing neck for less scroll wheel finger strain if I can make a significant line count reduction by using some of the vast darkness to the right. Long and narrow isnt always better than shorter and a little wider. (Yes fnarr fnarr but how would you say it)

[Zarremgregarrok]

If you have a (a call that needs a whole bunch of parameters.) you need to do some refactoring anyway.

[causa prima]

@Zarremgregarrok I've seen some very long parameter lists in Microsoft APIs.

[Zarremgregarrok]

@LorenPechtel Does that make it well written?

[Larswad]

I think the problem with 80-column enforcers is that they forget that the code instead grows in the vertical direction. You get the same problem, but in the vertical direction AND of top of this modern code looks awful when you have to break single statements over two or sometimes up to four or five lines. It is NOT more readable. With modern code I mean descriptive variable names and qualifying inheritance, namespaces, classes etc. Please stop the 80 column nonsese, use common sense instead. 120 is better, but should not be a rule either.

[bryc]

I'm not a fan of horizontal scrollbars

[Bersaelor]

Really bad idea when you want to use 'indents' and a monospaced fonts.

[gztomas]

The character limit does not tell you WHERE you have to split a line of code, but WHEN

[mtraceur]

I'm surprised no one has said this, given that I'm several years late to this discussion, but I think newlines (maybe with an indent for clarity) right before "extends" and/or "implements" keywords would still produce very readable code.

[phoenix]

Rust selected 99 as a sensible standard: aturon.github.io/style/whitespace.html

[aesede]

According to PSR-2: There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.

[micrub]

Visual field limits

[Ben]

@ToddChaffee I like plot twists in prose; not so much in code :)

[Todd Chaffee]

@ben so everything all on one line, right? ;-)

[Ben]

@ToddChaffee No, more the feeling that in some code variables change behavior in surprising, confusing, and sometimes devastating ways :) j

[Todd Chaffee]

@ben we aren't talking about line length anymore, are we?

[Ben]

@ToddChaffee I just thought too deeply about your simile haha. Those global variables in some code I inherit are used for too many things and it can take a lot of time to figure out where they're from, or what they're doing, or what they'll do to other variables. Stuff I would enjoy if they were characters in a novel.

[maaartinus]

@Bersaelor No, it works fine when you always indent using tabs only and set the tab width properly (width 4 monospaced are like maybe 7 proportional). Indentation works, you just can't do ASCII art, but I don't think ASCII art belongs in code.

[sola]

No it is not. If you write a longer than 80 chars line, you probably already have a problem in expression complexity or naming strategy. As others have mentioned, readability is a top concern and reading speed starts dropping above 60-66 chars (typography, based on human physiology).

[oligofren]

I love the fact that it says "it is very readable on one line" while at the same time I can't read the entire code snippet since it overflows the horizontal space in the browser. Point disproven.

[Sebastian Mach]

Personally, I am quite on the opposite side when programming. I find proportional code really hard to read. Sometimes, I even configure the IDE to use monospace fonts (yes, including menus).

[dawid]

@sola Your comment appears here with 98 chars, and it is a dense natural non-native language (to me) to understand. Completely legible. A code with until 3-4 indents, syntax markers etc. is even easier.

[Andy]

I accidentally downvoted this answer and can no longer upvote it. :(

[The_Sympathizer]

(As of 2020) Also, what if you have to read your code on a smartphone?

[The_Sympathizer]

I'd also add that if one is going to go wider with wanting to take advantage of a wide monitor, a good rule of thumb would be right hand scrolling is evil. Don't have to scroll right to follow a line of code.

[sola]

@vlyps It may feel completely legible but that doesn't mean that you couldn't read it much faster if it was shorter. Indents do help in general but not much when you are at 100+ chars per line.

[Khalil Gharbaoui]

Personally I think 80 encouraged... 80 - 85 is neglect-able. 90 - 100 is an absolute max. up to 120 is exceptional. Stick to 120+ you'll probably be in need of anger management therapie at some point. There is an Enter key on your keyboard you know 😏

[SacredGeometry]

@sola Nonsense! You are assuming there is no such thing as vertical noise. All that shorter sentences mean is that you have more bleed into the vertical which is just as legibly problematic. Often worse. There are better ways to structure code and any other language than an adherence to arbitrary character limits.

[SacredGeometry]

If you are working professionally on a 17" screen with a resolution of 1024x768 in 2022 then sorry you are not someone we should be caring about catering for. If your tooling is forcing that limit on you then you are using out of date tools. It's a very tenuously disguised mandate by bad programmers to try to force even worse programmers to write "better" code all it actually does, however is make everyone write badly formatted code.

[sola]

@SacredGeometry: The horizontal limit is not arbitrary. Human reading speed starts dropping above 60-66 chars width. This has been established by research ages ago and is the basis of typography and website design as well. Obviously, the code will be longer vertically but you will read through it much quicker, especially if correct indentation rules are observed.

[SacredGeometry]

@sola Those studies had literally nothing to do with programming they where to do with normal text (mostly) in the english language. They are pretty dubious not to mention especially when you consider that they contradict how many languages fundamentally work. Not to mention were part of the vast replication crisis in psych.

[SacredGeometry]

@sola This fashion of blindly espousing bad science as if were fact because someone has written a paper about it, rather than treating it as what it is i.e. merely popularised conjecture is pretty endemic.