Hacker News new | past | comments | ask | show | jobs | submit login
Why is 80 characters the 'standard' limit for code width? (programmers.stackexchange.com)
61 points by budwin on June 1, 2014 | hide | past | favorite | 44 comments



It's funny to start seeing more and more questions from people who started using computers with Windows 95.

Actually, not it's not, little punks making me feel old, get off my lawn.


Because an Emacs window split into two 80x25 frames fits perfectly on a 13" Macbook Air. ;)


Asker of the question here, you are indeed spot on, Windows 95 was the first OS I used!

The train of reasoning here reminds me of another story (which I think has been on HN before): Why is a space shuttle engine 4' 8.5" wide?

http://www.astrodigital.org/space/stshorse.html


Snopes suggests that story is a little inaccurate: http://www.snopes.com/history/american/gauge.asp


Hey.. I still remember my first programming experience with Turbo Pascal running with MS-DOS 5 and I didn't know how this 80 characters per line popped up in history. I remember there was something like .. "MODE CON..." that I could change the chars, but I didn't know why and how the defaults were settled everywhere the same. Kudos for the OP asking this question.


> It's funny to start seeing more and more questions from people who started using computers with Windows 95.

I don't know why they stuck with it!

C64s and amigas.. when computers were cool before microsoft ruined it! Now we've been saved by apple, hurah


> get off my lawn

no


Related is the question of why newspapers arrange their text in columns. According to another stackexchange thread†, studies as far back as the 1880s indicated that the optimal width for reading prose is 3.5 to 4 inches.

Of course, code isn't prose, but I'm still a fanatic about the 80-character limit. To assist with keeping lines of code short and sweet, I will often introduce aptly-named temporary variables and let the compiler sort out what's actually to happen.

I can easily fit four 80x84 windows on my external monitor (DejaVuSansMono 13 pt).

†http://graphicdesign.stackexchange.com/questions/3553/why-do...


While the initial reason may be historical, I've found that on smaller monitors 80 character width makes it just about wide enough to have two code windows side-by-side. That's why I usually tend to stick to that limit. Though on bigger monitors I often stick to 100.


80 or 100 is both fine, but I prefer 80. Shorter lines are simply easier to read.

It just like reading a text online. Most people would prefer shorter lines, compared to one extremely long one. It's simply easier to keep track of where you are.


I usually use 100 or 120. It is very useful for having many windows on emacs on a 1920x1080 monitor. Also it is good for github. Anything bigger would need to scroll horizontally for reading the code and that sucks


I always thought that it was because you might need to read or edit a file on a dumb terminal while troubleshooting a problematic system (eg, from single user mode or a rescue disk)


If I am on 3270 or 5250 I have 80/132 but for the most part even when using the PC based editors we have I find no issues with 80 columns because even on the wide screen monitor I have information panels and such taking up space, plus I can easily side by side code.

I am also of the opinion that like names, when the line gets too long the readability goes out the door


Java programmers have variables longer than 80 characters now a days.


Which is why when you see a codebase like Plan 9/9front's, you can't help but be in awe.

Most of their lines are incredibly compact. In fact, a lot of people who first read the code suffer a bit of a culture shock. It's just too... simple, and readable. Especially for C. This causes some to knock their own particular style of ANSI C as inadequate.

I think it's a testament to their genius. You'll probably never find a codebase as massive yet as readable and grokkable as theirs. If you're used to modern Linux code that copiously uses glib, D-Bus and a whole bunch of other libraries, you'll either find it a huge breath of fresh air, or completely blasphemous.


As a primarily Java programmer, those folks need to be drawn and quartered.


Don't go near Cocoa (/Touch) developers. You will be overtaken by rage.


I dabbled in this when I wrote an iOS game for fun. It was pretty surprising how quickly variable names got out of hand. Random iOS class name: AVPlayerItemLegibleOutputPushDelegate[0]. Then you try and make instances of it and you obviously don't want to prefix the class name with something or risk growing the name even more. And god forbid you try and extend the class and then make an instance of that using prefixes to indicate more specific objects.

0 - https://developer.apple.com/library/ios/documentation/AVFoun...


I've heard stories about one year at WWDC's Stump the Experts, they discussed the longest method name in ObjC land. I wish I had been there. I also wish I was going to be there tomorrow, but alas, the marketers and bosses have taken over.


Haha I am also a Java programmer. To be honest, I try and keep things as brief as possible, but I almost never sacrifice readability for brevity. So, I'll admit, some of my variable names get a bit lengthy at times; however, that is for all languages I program in, not just java.


Hey, leave those guys alone: It's Objective-C who has the biggest names of them all. It's class names that are huge anyhow in Java. Both are huge in Objective-C (class and variable)

  --Objective-C Dev who sorely wants namespaces


80 characters is also comfortably within the limits for presenting code in most books, except for pocket reference sized books. The actual limits for most books are about 85 characters, so that leaves some leeway.

Even if I have the screen real estate, I don't think I'd want to intentionally write wide code, and I like self-explanatory names. On a 4k screen I might like Eclipse layouts that put the logging next to the code, rather than have very wide code.

Has anyone created examples of code that gains readability from being wider?


60 to 90 characters per column is widely used in typesetting for good readability. It’s probably not a good idea to go very far beyond 80 characters or so purely for readability, no matter the context.


Well context matters, especially if your language has you starting with at least two or three tabs for most of your code:

  package Foo {
      class Bar {
          void baz() {
              // Most code is nested *at least* this deep.
          }
      }
  }


IME, there is a very strong correlation between good developers and short lines. Bad devs doesn't mind if some lines are 150+ chars long and require horizontal scrolling. They also don't care that much about consistent naming of symbols or having correctly indented code. There are very strong reasons for keeping your lines short, naming consistent and indentation in check. But at the end of the day, you either "get" it or you don't.


For me those things are almost like a book cover. If I open a file and I see freakishly long lines I just assume that the content will be not well crafted.


Back in the day, I used punch cards in college computer courses. Languages like FORTRAN, COBOL, and assembler were column dependent, e.g.

Col. 1 : Blank, or a "C" or "*" for comments Col. 1-5 : Statement label (optional) Col. 6 : Continuation of previous line (optional) Col. 7-72 : Statements Col. 73-80: Sequence number (optional, rarely used today)

With the sequence numbers if you dropped the deck and scrambled the cards, feed the pile through a card sorter machine to put them back in order. If you didn't bother with sequence numbers, another technique was to use a magic marker to draw patterns on the side of the deck to help with resorting it if you dropped it.


I never bothered with sequence numbers. Boy was it a joy to put your card deck in the reader and wait at the self serve printer, and have your program compile, run, and produce the correct output the very first time !


Just confirming that 80 characters is an idiotic and arbitrary "standard", propagated by nothing much more than cargo-culting

"Oh but it fits my screen, fits two-by-two on my screen" change font size, unless you're using the native 80x25 PC display (some kernel developers use that)

I can't imagine a worse use of developer time than making everything fit exactly inside 80 columns

Of course, not having a limit is bad as well, but the main issue is having a hard limit


I think the rationalizations devs use to defend their arbitrary choices are fascinating. Readability? My dead-tree Wall Street Journal uses 30 character width columns. NYTimes online is about 70 chars. New Yorker about 80. Textbooks, paperbacks, magazines, newsletters... all have different char widths. Yet I've never suffered an aneurism reading any of these things. The fact that it doesn't matter much would be sacrilege to most devs.


>propagated by nothing much more than cargo-culting

It's propagated because it's a standard, and it seems many people ARE comfortable with it. It also seems that I enjoy my font-size just the way it is.

I've just written my first reusable, outlive-my-employment level of code, and keeping my code under 80 lines was trivially easy. The only thing that was the slightest level of nuisance was that the function parser in notepad++ couldn't cope with a multi-line string definition inside a function.

The bulk of my time was writing clear, understandable and educational documentation for the library.

Why are you so hostile?


I personally don't like such limit. It's a relic of the old hardware. There is no need to follow it.


Old computers (Spectrum, MSX) had 40x25 = 1000 character screens, because memory was scarce, and 1000 is a nice, round number.

From there, they upgraded to 80x25 (doubling the resolution!). Two things happened to make it possible: 1) memory got a bit bigger 2) computers started shipping with dedicated higher-quality monitors (e.g. MSX-2) instead of being hooked up to TVs, so it was actually possible to read 80 characters on a line, even though you had to squint a little.


Terminals were commonly 80 characters wide, which doesn't explain anything. Why were terminals commonly 80 characters wide? Perhaps terminals were commonly 80 characters wide because punch cards were commonly 80 characters wide, which doesn't explain anything.

Eighty characters is the "standard" limit for code width because eighty characters is the "standard" limit for code width.


It doesn't explain everything, but it does explain quite a bit -- notably it traces the history of the standard back to punchcards.


Sure, the number 80 may be rooted in a very old design decision, but that doesn't mean it's necessarily bad or suboptimal because of that.

More isn't better in this case. When text gets too wide, it becomes harder to move your gaze from end of one line to beginning of another.

Also, the best number is probably not a hard limit, but a guideline/average to aim for.


Amusingly, I dismissed the original Apple Mac when it came out, because it couldn't display 80 columns of readable text.


The reasons why terminals are 80-character wide are well known and well documented all over the web. What's sad, is that newbies still have to ask on stackexchange or Hacker News about it, not knowing how to use a search engine. What are pupils taught in schools nowadays????


120 col 4 space tw real tabs ftw! unfortunately thats sort of flamebait.


The most popular text mode on older computers was 80 chars wide. That's really it. No other reason.

I use 120, plenty of space to fit two code windows side by side and one file browser.

With HD screens and the verbose languages we use these days (and verbosity is not always bad), it's a bit silly to try to stick to 80 char cols.


100-120 is definitely a lot more comfortable for most situations. It's good to have a width limit, but sticking with 80 for tradition's sake can often be worse than having none at all.


So how much of your code goes past 80 chars? What part of it is taking up the most space?

Feel free to add any other details, like the kind of programming you do, what language, etc.


Obj-C / Cocoa uses very long variable names. Someone mentioned this in a post above with a link for example. It's very hard to stick to < 80.

            leftWall.physicsBody = [SKPhysicsBody bodyWithRectangleOfSize:CGSizeMake(100, wallHeight)];
close to 100 characters.


It'd be nice if when people down-mod a post, they give a reason. The way it works is just useless.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: