I think the biggest problem with translating this into code widths is that we use indentation liberally. Seeing 6-12 characters taken up by whitespace is nowhere near uncommon.
So, given that, perhaps 80 characters isn't so tyrannical...
I've seen code where 20-odd characters were taken up by whitespace. Of course, at that point, you really want to split it out into different, named functions... code like that is unreadable for entirely different reasons than line lenth. Similar things the case for almost every single case where a line might become "too long" - I don't think the length is actually the issue so much as the complexity.
8 chars is default tab size. So e.g. "git diff" shows you 8-position tabs. Github (and Bitbucket, etc.) diff visualizer also shows it as 8 positions. Any editor should use 8 by default, too.
And, believe me or not my space-loving friends, tab-indented codebases still exist.
My first change to any editor is to set tabstops at 4 characters. That's the standard policy at my employer, and I like it for my own projects, as well.
For code it also seems most of the text reside on the left. Opening an extra wide window to display text for the occasional long line seems a waste of screen space.
Indeed. The rule for prose is that a text block width should be somewhere between 2.5 and 3.5 full alphabets. This takes into account the variable spacing of different characters. This is to strike a balance between having inconsistent space or too much hyphenation (if the line is too short) and the eye's ability to find the next line when scanning leftwards from the end of the previous line (which is difficult if the line is too long).
Code is different in several ways. Firstly, code is generally shown in monospace typeface. Secondly, breaking lines too early can be even worse for code than for prose. Thirdly, even with a long line limit, code will generally have lots of short lines anyway, and this helps the eye find the next line when reading. The long lines (as long as they aren't all long) stick out from the rest of the code text, making it easier to read.
While the first example of car sizes and Roman chariots is likely incorrect (as the article itself points out, and it's also suspiciously familiar to the debunked railroad gauge/Roman chariot story[0]), I'm always fascinated by stories like this. It underlies the organic nature by which many of our systems have grown.
The same kind of "cruft" you see in systems and designs that have been around for a long time (Why is it the "Referer" header in HTTP? Why do we still call it Ajax/XHR when XML is rarely used?) is seen in many aspects of life.
Etymology is choke full of them. Consider the word, "consider" - its roots may have meant something like "consult the stars" at one point in time. (I think I first read about this in Sagan's Cosmos)
I always thought it was because on slow modem connections the traditional arrow keys could become unreliable. Vim supports use of the arrow keys, but back in the day when I tried to use them over a modem occasionally the sequence would be interpreted as escape then garbage, breaking me out of editing mode and sending some unsuppported command to the vim. That's why I learned to use hjkl instead. Those keys are also reliably placed on Qwerty keyboards, whereas any other keys may or may not remain in a sensible location, especially back in the old days before keyboard layouts settled down.
I don't doubt that the author's story is correct, but I think that 80 is a perfectly reasonable number to have as a standard. It's very annoying when I read code that doesn't use the 80-character limit, because my terminal is not guaranteed to be as wide as theirs, and I really don't like resizing my terminal window to fit their line length.
For car width, I think that that's also a pretty reasonable width, since it's the perfect width to fit two people side-by-side comfortably, with a bit of room in the middle.
Now we only need to think of things that have developed for historical purposes, yet are not reasonable defaults.
> It's very annoying when I read code that doesn't use the 80-character limit, because my terminal is not guaranteed to be as wide as theirs, and I really don't like resizing my terminal window to fit their line length.
Considering the numbers of programmers in the world, and how long they've been working with text, and how much annoyance text breaks / line wrapping / format flowing causes it's kind of surprising that there isn't better ways of wrapping lines without line breaks.
What's current best practice? Or is it just down to the project style guide?
I guess these are enough general: put operator sign before line break; don't break inside of the most nested expression; don't break between variable type and name...
There are more such rules which differ between standards (like Linux kernel style vs. PHP PSR-2 style), e.g. how to pad trailing lines of function call. Linux style says to align trailing lines at offset next to the opening brace. (This doesn't look good in case of long function name, though, but most of time readability of this way is very good.) K&R is referenced as an original of such style, just as everywhere in Linux coding style. Also Linux coding style is not just what is told in Documentation/CodingStyle - there are some unwritten tools which you'll encounter when you run scripts/checkpatch.pl or get reviews on your patch submission.
gofmt comes to mind here. It renders the particulars of what you do while writing a non-issue by taking any valid Go input and producing a "canonical" final formatted version.
It used to seem natural to me, but as screens have gotten wider, it now seems like I usually have my terminals set wider when I have two set side-by-side. Even on my relatively small laptop screen.
I actually was just contemplating ditching the 80-char limit the other day, at least for personal projects.
80 characters seems really narrow. IDEs like IntelliJ put a guideline at 120 characters, which basically allows two full width editing windows side by side (depending on your font size) at the pretty standard resolution of 1920x1080.
We've all got widescreen monitors now, right? So it makes sense that people are going well past 80 characters.
Sure we do, but some/many of those widescreen monitors are only eleven or thirteen inches diagonally, and can't reasonably fit two buffers of text 120-chars wide without shrinking the font to eye-straining sizes (yes, even on retina screens).
Plus, this only gets worse as you get older and your eyesight starts to diminish.
As another commenter noted, it's not (just) about screen width. It's about having a text width that allows your eyes to track both column boundaries as achoring points. If a text is too wide, your eyes will have trouble finding the start of the next line.
For the same reason, newspapers use multiple columns, even though the paper itself would allow for 200-character lines.
Most of this line length theory isn't backed up by any science. Newspapers are a particularly poor example as their line lengths are typically much too short to provide "good" readability.
It's also worth noting that newspapers traditionally used columns because they allow individual articles to be typeset and then divided into pieces later during composition. Not because they offer some kind of readability advantage.
Newspapers can be extremely unreadable though for this exact reason. They often use 30 character columns, then have an article consisting of 5 or more such columns of text. I often "get lost in the sentence" when reading this format and have to backtrack. It would be interesting to know why they do this. It is definitely not readability.
I think on a mental level, the problem is that when the lines are this short, the grammar is extremely broken up, so you need to "cache" 4-5 lines of context to understand anything. When it's 80 per line, lines are parsed in a more independent fashion.
I think 70-100 is perfect, depending on other factors.
Python too, because you're forced to indent. One line of moderate length explanatory text out to console in the middle of an if: block, and you have to resort to silly tricks[1] to remain PEP8 compliant.
If you weren't forced to indent when appropriate, and chose not to, I think that would damage readability even more.
There are contexts when Python doesn't force you to, such as the example the article shows as "ways [that] actually make our code less obvious and less readable":
err("HTTP 403 Forbidden -"
" Does your bitbucket user have rights to the repo?\n")
But if you indent it properly, I don't think it's less readable than the extra-long-line-with-scrolling:
err("HTTP 403 Forbidden -"
" Does your bitbucket user have rights to the repo?\n")
The reason I complain about that err() example is because it relies on very un-pythonic behavior. You're one stray comma away from sending in a tuple rather than a silently concatenated string.
(Coincidentally, this is why the separator there is a dash, rather than the more grammatically correct comma)
And I thank you for the other examples of ways to handle the URL, but again we've moved into making changes for very minor benefit just to please the analyzer, rather than the human reading the code.
Yes, widescreen monitors are great - now I can view three editors side by side at standard line length!
I used to work at a dysfunctional startup which could not agree on any sort of coding style conventions, and one of the other devs would just zoom his Visual Studio window fullscreen and type, type, type until he bounced off the far edge, no sense of column width at all. His code was excruciatingly terrible for a lot of reasons, but at least it was easy to spot since it looked just as messy as its structure.
> For car width, I think that that's also a pretty reasonable width, since it's the perfect width to fit two people side-by-side comfortably, with a bit of room in the middle.
How do you know the width of a standard human isn't determined by 2000 years of people choosing partners that would fit beside them on a cart comfortably.
Agreed, 80-chars may be an accident of history, but it's an accident which happens to line up quite well with the human eyes ability to track horizontal lines of text.
It gets tiring listening to devs rage about the 80-char limit, then go on to produce code that's basically unreadable because it scrolls way off the screen.
I was looking at some C code of mine that is ~30 years old - it was written on 80x24 serial terminal in vi and I was fairly pleased with how readable my code was. I suspect a large part of that was the short line lengths!
From observation, people on HN tend to discourage small replies that say nothing (such as this). It is likely that you would not have got downvoted if you had said what evidence you have to the contrary, given your opinion on it and why you think that, or even made an effort to debunk or state why you think a few common arguments for the line length being 80 chars are incorrect.
Hacker News keeps clean discourse by downvoting comments that are not relevant or do not stimulate debate.
It goes both ways. If you break in the middle of the line just because you need to follow the standard, you may end up breaking in the middle of a construct that is really meant to be read as a whole; and having to move your focus to from the end of one line to the beginning of another is quite disruptive to the flow.
I'm also not convinced that 80 chars "happens to line up quite well with the human eyes ability to track horizontal lines of text". It's claimed often, but in the absence of any actual studies, the best you can really say on this is that it is your subjective experience. Mine is different - I find 100-120 columns per line to be eminently more readable.
Until the aforementioned study determines what the average peak readability length of _code_ (which I think is likely to be different from regular text, because the semantic units are different between the two), we'll just have to agree to disagree.
I've heard this reasoning (that 80 col terms are directly due to the 80 cols on a punched card), but never any proof.
Frankly, it sounds like numerology, to me.
"Hey! Both these numbers are 80, and they describe closely related dimensions. No way that's a coincidence! The newer one must have been specifically chosen to match the older one."
While it could of course be true, until I see reasonable proof, I'm going to assume that both values were the outcome of fitting a data representation (holes or characters) into a size that was effectively fixed for other reasons (standard card size, commonly available paper and CRT widths).
Especially since IBM later put out 96 column cards.
Going to go with the fact that original cards were the same size as paper currency at the time and re purposing of equipment to handle paper currency was the expedient thing to do.
The article has the causality backwards. We don't use 80 characters because that's what the Hollerith card used, the Hollerith card used 80 characters because that's a good ergonomic width. (Or, if you prefer, the Hollerith card succeeded because it was a good ergonomic width.)
Coincidentally (or perhaps ironically) the article itself is formatted for ~80 characters per line, not because it's bound by the Hollerith card, but because 80 characters is a good ergonomic width.
I agree, and I was thinking the same thing as I read the article. Even so, I'm glad we're talking about history. 79 or 81 characters would be pretty much the same. You have to know the history to understand why 80 is a magic number.
And why does my terminal window have a baud rate? Why is it so slow?
A little offtopic and showing my age, but in 1985, personal computers were still a little expensive, and my high school couldn't afford an Apple ][ lab yet, but we did have a Digital PDP-(something) mini computer with a card reader (probably a donated relic).
In my grade 10 "Data Processing" class (when was the last time you heard someone use the term Data Processing?), we had to use IBM cards with a Sharpie (the card reader was thankfully an optical reader vs a punch card reader) to write programs in BASIC (when BASIC still used line numbers). When we had tests, we had to basically write our programs at our desks on cards, run to the card reader to run and check our results on a printout. It made for some hilariously tedious debugging cycles.
If my memory serves correctly, back in that era, having an 80 column card on your Apple II was something worth bragging about.
Yep, a pretty serious piece of kit, although you really needed a monochrome monitor for it to work properly ... regular TVs didn't have the horizontal bandwidth.
Not at all. The H-card dates back to 1890, and punched cards in general go back a lot earlier than that. Given the technological limits of the day, the H-card is actually quite a good design.
Also the author seems to have missed that this char limit is changing. In Python, for example, an official style guide update in 2013 [1] allows for 100 char line length.
To clarify, PEP 8 nonetheless recommends that lines be limited to 79 characters, and even recommends capping docstrings and comments to 72 characters. The python standard library follows those guidelines.
The 100-character allowance is for code "maintained exclusively or primarily by a team that can reach agreement on this issue".
Exactly, for readability a printout should be 10 characters per inch, which on 8.5 x 11 paper means 80 characters max with .25" margins on either side. It would perhaps be better argued as the tyranny of 10 point type :-)
I think this might be a case of two-way causation, though.
~80 characters is a good, readable target, but that's not what we have. For a long time, we've had a militant standardization on <81 characters, even in cases where the results are obviously worse than a long line. I imagine that all of us have read or written code containing a line break that blatantly decreased clarity.
So the question remains: why 80? 80-ish, sure, but why such a fixed standard? I don't know enough history to say if that's down to Hollerith cards, or the consequences of auto-formatters, or something else, but there's a more definite question than "what's a good width" here.
I researched Hollerith cards and 80-character lines in excessive detail while studying card sorters [1]. The Hollerith card is the root cause of 80-character lines, of course. Prior to 1928, Hollerith cards used round holes and 45 characters per card. IBM wanted to fit more data on a card and investigated two alternatives: binary coding so 90 characters could fit into 45 columns of holes, or rectangular holes which allowed narrower holes so 80 columns would fit. They chose the latter because it was more compatible with existing card sorting equipment, and the rest is history. Competitors used 90 column cards, but didn't achieve the same success as IBM. IBM later introduced 96-column cards, but they weren't as popular. Thus, it's just a historical accident that everyone uses 80 columns rather than 90 or 96. And 80 columns is used because that's how many could fit on a punched card the size of obsolete US currency. Note that ergonomics has nothing to do with the success of 80 columns: for the most part these cards held accounting data, not program code or text. (I wrote an article covering this in great detail but haven't posted it to my blog yet; hopefully I'll get it out soon.)
The facts you cite are true, of course, but it does not follow that the H-card was the cause of 80-character lines. We've had plenty of opportunities to ditch that standard if we wanted to. The Apple II had 40 characters per line. That went by the wayside not because there was a compelling reason to be backwards-comatible with H-cards, but simply because 40 characters is too short. When longer lines were enabled by technology we went to 80 rather than (say) 132 because 132 is too long. We can quibble over 80 vs 90 or 96 (or 72), but it's pretty clear that the sweet spot is right in there somewhere. It is not at all like (say) electrical outlets where we really do have to do deal with all kinds of crazy incompatibilities when traveling for no reason other than historical accident.
The jump to 80-column video displays was due to late 1960s CRT-based computers for data entry such as Four Phase and Viatron, which allowed people to enter punched card data on a screen and edit it. These of course had 80-column input. These were followed by more general purpose video displays like the VT50, which also had 80 columns for compatibility with punched card systems. This led to terminal emulator windows such as xterm using 80 columns. It is a clear historical path. (I don't know why you're bringing the Apple II into this.)
You could buy an 80 column card for your Apple II. It usually needed to be turned off for games and such that were depending on the 40 column format, but that was hit or miss.
132 was too long given the resolution of displays at a time. I don't think it necessarily says anything about the easiness of parsing a string that long per se.
> Note that ergonomics has nothing to do with the success of 80 columns
I don't think that's true at all. While 80 columns becoming initially common for displays was no doubt a product of the H-card, the fact is that there was reasonably widespread support even fairly early in the pre-GUI PC era for alternatives -- both more and less, but probably most notably in use 132 columns -- for display, printing, etc., and they were used where they offered superior utility. But, outside of a few niches, 80 columns stuck even in the face of alternatives, and the reason it did so was ergonomics.
The vertical height of characters was dictated by the number of scan lines in the display. It was impractical to use displays that weren't compatible with TV standards, so that meant 240 non-interlaced scan lines. 10 pixels is about the smallest height you can make a font including line spacing, so that's how you get 24 rows.
Once you have the number of rows, you want the number of columns to have a good balance. 80 columns gives you well proportioned characters, where other alternatives e.g. 132 do not. Add that to the historic precedence and you have the makings of a standard.
Teletypes were in common use on the first time-sharing systems, and those were only 72 columns wide. Consider yourself lucky to have those extra 8 characters.
> When the Type 80 sorter was introduced, standard AC power hadn't fully taken over and parts of the United States used DC or 25 Hertz AC.[9] Thus, the sorter needed to handle fifteen different line inputs including unusual ones such as 115V DC or 230V 25 Hertz AC.
Really enjoyable article, thank you -although, could I possible talk you into an honourable mention of the 1801 Jacqard Loom which used punch cards to store patterns? :)
I use a portrait-mode monitor for coding, with 128 columns. Honestly, 80 is Just Fine by me. It is a nice readable width, and I don't mind wasting ~⅓ of my screen.
emacs, submlime, xcode can soft wrap code well (indenting a little extra on the wrap). wrap for semantics, not any arbitrary boundary, and then you can view the code perfectly across many different resolutions & window configurations (2-up, 3-up, whatever).
Someone already knows the answer to this, (but not me): if you examine a statistically representative set of ancient books, (both pre- and post- Gutenberg) what is the average line length? And doesn't that partially depend on "standard" parchment/vellum size? And doesn't that depend on the size of a young sheep's belly? ("The tyranny of the size of sheep!" Where's James Burke when you need him?)
Interesting fact: the Hollerith punched card is the same size as the dollar bill in 1890. This is because Hollerith was able to take advantage of existing stacking and sorting equipment already designed for banks.
Strangely, punched cards are just a bit bigger than the old US currency, not exactly the same size. Also strange: nobody knows exactly how big the old currency was. To be precise, there are three slightly different sizes quoted as the official size. I asked the Bureau of Engraving and Printing about this - they print the money so they should know - and they couldn't explain the discrepancy.
> Allows you a larger format for detailed or spread sheet work so you can preview reports prior to printing. (Note: The advanced video option, which is standard with the VT102 and VT131, provides 132 column × 24 lines display.)
I'm not sure what the vt100 resolution was, but later terminals allowed you to download your own bitmaps. According to (http://www.vt100.net/docs/vt510-rm/DECDLD.html), these bitmaps were:
"10 pixels wide for 80 columns, 6 pixels wide for 132 columns."
If their baseline was 800 pixels (80 cols * 10 pix/col) then 132 is the largest number of columns fitting into 800 pixels at 6 pix/col.
That's a good question, and I've been trying for weeks to find the answer. 132 columns for printers is way older than video terminals, dating back to the IBM 1403 printer from 1959. I've studied the 1403 printer closely and asked the IBM history experts, but nobody seems to know exactly where 132 columns came from. One theory is IBM wanted to have more columns than competitors with 120 columns, so went to 132, but that's not a completely satisfying answer. I wonder if 132 is a limit due to the (surprisingly complex) timing of the print chain, but haven't been able to nail it down. I've studied the 1403 printer's circuitry in detail, and haven't seen any reason for 132 columns. If the printer had 12 characters per inch, 11 inch wide paper would have 132 characters, but the printer has 10 characters per inch so that doesn't explain it.
Apologies for being somewhat off topic, but does anyone know where I can go these days to get some cards punched (for a small museum display)? Given how common punchcards were, it has been difficult to find someone. Anyone out there have access to an old IBM 026, 029, 129?
The Computer History Museum in Mountain View has 026 and 029 keypunches. Go to the 1401 demo and they'll probably let you punch a card. Or let me know what you need punched and I'll see what I can do. What museum are you getting this for?
If you're in the bay area, you should go see the IBM 1401 demo; it's cool to see a punched card computer in operation. Demos are Wednesdays and Saturdays; schedule is http://www.computerhistory.org/hours/
The Living Computer Museum in Seattle has a keypunch - ask a docent and they'll turn the machine on, give you a card, and a bit of instruction and you can have at it.
I'm not sure whether it will be of any practical use, but the Computer History Museum in Mountain View has an IBM 1401 on display, along with some IBM 026 card punches. They do demos of the hardware, and they'll sometimes punch little bits of data into cards, if you request it (my wife got our names punched in). I don't know about larger requests, like punching realistic program data into multiple cards, but it couldn't hurt to ask, right?
Except for Linux Kernel people (who actually have to work and debug stuff in the builtin 80x24 screen) there is no excuse for not using something bigger
Having to break a line because it's 81 characters and your linter is going to complain is completely and utterly ridiculous
It's 2016. How long since the first IBM PC again?
Yes, it's a tyranny. I don't care if the average is around 80 columns, I care about having a hard limit
My current terminal is 110 chars wide, and that's because I use a bigger font.
If eyes were easily repairable I might agree. But I figure at some point in my life (even though I keep my fonts larger than I need to) I'm going to need even larger fonts. I'd rather write code my future self will have less trouble reading, especially since I might be sharing my code with others who have poor eyesight now.
80 is an _awful_ width for code in a programming paradigm encouraging long variable names. If you're comparing two values from class.accessor, you fly right past 80 characters if you have any indentation at all. Namespace hierarchies pretty much put you over the limit if you use named constants in your constructors.
If you actually use long/descriptive variable names, you can mentally process much wider text quickly, invalidating the research the "80 character optimization" was based on.
Personally I use a 145 character width, because that fits nicely on my portrait-oriented monitors, with room in both left and right margin for the editor to highlight/mark. 80 character wide limits on a modern project is like an adult riding a "Big Wheel".
That's from emacs. It's a bit hit or miss whether editors do something nice like the above, or just indent the arguments by one stop, but other options seem to be fairly rare.
I generally have one function call per line for ease of debugging. Nothing worse than having to do a fiddly step in/step out dance when you're trying to think about what's going on. But it's also good for keeping on top of line lengths too.
Including class variables? Their context is far larger than the immediate code you're looking at, longer/descriptive names seem basically required there, as they have essentially similar scope to functions. (Same logic applies to making them longer) You'll note... that was my original example.
You mean field names? A paradigm where you have such a thing is _awful_. Seriously. And this is exactly one of the reasons why it is awful and why it leads to an unreadable and unmaintainable code.
And no, I don't believe you. Making your variable names more descriptive does not make your code less readable. Even when it's not strictly necessary, it's not harmful to comprehension UNLESS you refuse to move from a completely outdated line width.
Some people argue that it takes longer to type and edit. But as we all know, we spend far more time reading than writing code, and modern editors (like vim!) have solved this non-problem anyways.
Long variable names are great. When used in conjunction with redundant variables for intermediate computation results (effectively naming those results), they can make a terse but complex expression much easier to read and understand, to the point where something that required a comment no longer does so.
strpbrk() is a bit too short for my taste, but I'll choose that over FindFirstOccurrenceOfAnyCharIn(). There's "long and descriptive", and there's "too long".
Think about it: there's a reason why human languages are filled with pronouns, because if you use the full name for everything, communication will soon become tedious and it will become actually harder to understand.
Any desire for a long and descriptive name should be tempered with a matching desire for conciseness. Otherwise you end up with names like MaybeUpdateDisplayParameterListForValidation. Throw twenty of these names onto a screen, and I have no idea what the hell is going on: I can't even figure out which names are the same at a glance.
The problem with these examples of verbose functions is not that they're verbose, it's either that they encompass too much functionality or poorly describe what they do.
Human languages also solve it by taking into account context - and so do PLs. For example, if your language can overload functions based on argument types, then "Char" is already redundant.
The "break" and "span" terms were familiar from a time when more people knew the Snobol language, which has two frequently useful pattern matching operators: BREAK and SPAN. Snobol's BREAK(S) pattern matching operator matches the input up to but not including the single-character match for any of the characters in set S. The set S delimits or "breaks" the sequence. SPAN(S) matches a sequence of one or more characters from the set S.
strpbrk tries to fit "string" "pointer" and "break" into a symbol that is different in the first six characters. It was once a common linker limitation that only the first six characters of external symbols were stored.
Actually the C function which corresponds to the concept of BREAK is strcspn (complemented span), because this gives the (length of) the range characters up to the first match in the set. That is to say, strcspn could have been called strbrk! Then we would have had strspn and strbrk as a complementing pair. In any case, the strpbrk function points one character past the substring indicated by this function; giving a pointer to the breaking character. I think, the following equivalences hold:
which further supports strbrk as a good name for strcspn.
Trivia: break and span appear as functions in the Scheme SRFI 1, by Olin Shrivers [1998]. I think these correspond to the take-while and drop-while in Clojure and imitations thereof like the Emacs Lisp dash library.
Yes; that reason being that we don't have the same strict limits on number of characters in an external name, and we simply have too many API's to remember to be able to give six character mnemonics to them.
Short names are not left behind in core languages. For instance, a function that gives the length of a list, string or other sequence is often called length or len, and not length_of_sequence or whatever.
Arc, in which HN is programmed, has reduced "lambda" to "fn". "fn" is the same sort of shortening as using "pbrk" for "pointer to break".
Ruby has shortened "print" to "p".
For the basic core of a language, shortening names is good. When you're reading code, the short names by their very brevity tell you "I'm a thing in the core language, and not some external API to some add-on lib", which also has connotations of "I might be useful in many contexts; it may be worth it to learn about me and remember me".
You know, those kinds of history forcing itself into modern standards only happen when the historic one isn't inconvenient.
When compatibility is a burden, people do work hard to break it.
Anyway, there's a "(2012)" missing on the title, and even that makes the article kinda late to the discussion. By that time, most people already didn't care about the 80 lines limits.
The first railroads in the US and UK standardized fairly quickly on 4'8½", but that's not the only size (even today!). The Great Western Railway, for example, was infamously at a 7' gauge. Even in the US, most railroads in the south converged on a 5' gauge until they shifted to 4'9" (not 4'8½"!) on May 31, 1886. The gauge differences in very early (1820s and 1830s) railways were just as diverse as the coal tramways that proceeded them--which means you basically have every value between 4'6" and 5' as the actual track gauge.
Of course, that belies the fact that your track gauge does not determine what you can stick on a train. That's the loading gauge, and these are nowhere near as consistent. The UIC standard loading gauge in Europe is 3.15 m wide, while the standard US loading gauge is 3.25 wide--and they both share the 4'8½" track gauge. (Note: the actual adherence to these standards, particularly in 100+ year-old railways, is a different matter.)
A someone who believes proper non-abbreviated naming is essential to maintainable code I think the 80 char/line practice should be dead already.
A couple 14 char class names and some indentation and suddenly everything is a formatting contortion, even if the average content length of a line is well under 80, occasional outliers and moderate indentation (at least 3 or 4 indentation levels are common in object oriented languages from class declaration to control flow) and it's well worth it to use 120 char lines.
(And if you write Java you probably need even more space to handle stuff since class names are often a ridiculous number of words long...)
Outside of programming languages, I also think the 80 char limit is terrible for readable html or html templates.
This is the first reasonable thing I've read in this post. I can't believe that upthread someone actually proposed limiting variable names to four characters to keep the 80 char limit!
> But breaking the statement arbitrarily at some point
> seems more like saying that you have to end a sentence
> at the end of each line, whether the sentence is finished
> or not because, you know, that's the way it's always been
> done. (I know it's not a perfect analogy.)
Isn't it more like line-breaking sentences at the edge of a paper page, which we do, and which is perfectly reasonable because of the page's fixed size?
Sure, you can design your document for a different paper size, but then you have to reconfigure the printer for that size, make sure you have the right paper size loaded in the printer (and change it back afterwards!), get new envelopes in the new size, get new binders...
Similarly, if I read a program wider than 80 characters, I have to resize my terminal window and my Emacs window. When I then switch to working on other programs in the same windows, those programs then tend to be infected by wider-than-80-character lines, unless I remember to resize things back to normal, which in turn perpetuates the problem. So either the applications would have to constantly resize themselves when I switch between files (which seems really annoying) or we could just decide to stick to the standard 80 columns which, as many comments here have pointed out, is a reasonable choice to standardize on even if it's arbitrary.
> I have to resize my terminal window and my Emacs window.
Should be an option to auto resize or auto wrap
> When I then switch to working on other programs in the same windows, those programs then tend to be infected by wider-than-80-character lines unless I remember to resize things back to normal, which in turn perpetuates the problem.
Why would a program care about what size the window was when you ran it in the past?
> So either the applications would have to constantly resize themselves when I switch between files (which seems really annoying)
147 comments
[ 2.1 ms ] story [ 199 ms ] threadSo, given that, perhaps 80 characters isn't so tyrannical...
And, believe me or not my space-loving friends, tab-indented codebases still exist.
Code is different in several ways. Firstly, code is generally shown in monospace typeface. Secondly, breaking lines too early can be even worse for code than for prose. Thirdly, even with a long line limit, code will generally have lots of short lines anyway, and this helps the eye find the next line when reading. The long lines (as long as they aren't all long) stick out from the rest of the code text, making it easier to read.
Second, we code very differently then we used to - several layers of indentation are common now but were not when the limit was seen as reasonable.
The same kind of "cruft" you see in systems and designs that have been around for a long time (Why is it the "Referer" header in HTTP? Why do we still call it Ajax/XHR when XML is rarely used?) is seen in many aspects of life.
Etymology is choke full of them. Consider the word, "consider" - its roots may have meant something like "consult the stars" at one point in time. (I think I first read about this in Sagan's Cosmos)
0. http://www.snopes.com/history/american/gauge.asp
1. http://www.etymonline.com/index.php?term=consider
(then again, maybe the original keyboard maker put them there for ergonomic reasons)
[0] http://www.dictionary.com/browse/chock
For car width, I think that that's also a pretty reasonable width, since it's the perfect width to fit two people side-by-side comfortably, with a bit of room in the middle.
Now we only need to think of things that have developed for historical purposes, yet are not reasonable defaults.
Considering the numbers of programmers in the world, and how long they've been working with text, and how much annoyance text breaks / line wrapping / format flowing causes it's kind of surprising that there isn't better ways of wrapping lines without line breaks.
What's current best practice? Or is it just down to the project style guide?
There are more such rules which differ between standards (like Linux kernel style vs. PHP PSR-2 style), e.g. how to pad trailing lines of function call. Linux style says to align trailing lines at offset next to the opening brace. (This doesn't look good in case of long function name, though, but most of time readability of this way is very good.) K&R is referenced as an original of such style, just as everywhere in Linux coding style. Also Linux coding style is not just what is told in Documentation/CodingStyle - there are some unwritten tools which you'll encounter when you run scripts/checkpatch.pl or get reviews on your patch submission.
I actually was just contemplating ditching the 80-char limit the other day, at least for personal projects.
We've all got widescreen monitors now, right? So it makes sense that people are going well past 80 characters.
Sure we do, but some/many of those widescreen monitors are only eleven or thirteen inches diagonally, and can't reasonably fit two buffers of text 120-chars wide without shrinking the font to eye-straining sizes (yes, even on retina screens).
Plus, this only gets worse as you get older and your eyesight starts to diminish.
Yup, I'm at that point.
For the same reason, newspapers use multiple columns, even though the paper itself would allow for 200-character lines.
Or if you have something like this:
You're only reading the "User.findUserBySomething". The rest of it is mainly fluff.It's also worth noting that newspapers traditionally used columns because they allow individual articles to be typeset and then divided into pieces later during composition. Not because they offer some kind of readability advantage.
I think on a mental level, the problem is that when the lines are this short, the grammar is extremely broken up, so you need to "cache" 4-5 lines of context to understand anything. When it's 80 per line, lines are parsed in a more independent fashion.
I think 70-100 is perfect, depending on other factors.
Screenshot of what I mean: http://www.trbimg.com/img-5667d3f6/turbine/la-la-na-menace02...
[1]: https://tkware.info/2016/05/08/a-case-for-increasing-pep8-li...
There are contexts when Python doesn't force you to, such as the example the article shows as "ways [that] actually make our code less obvious and less readable":
But if you indent it properly, I don't think it's less readable than the extra-long-line-with-scrolling: The other example, could perhaps be written as or like this:(Coincidentally, this is why the separator there is a dash, rather than the more grammatically correct comma)
And I thank you for the other examples of ways to handle the URL, but again we've moved into making changes for very minor benefit just to please the analyzer, rather than the human reading the code.
I used to work at a dysfunctional startup which could not agree on any sort of coding style conventions, and one of the other devs would just zoom his Visual Studio window fullscreen and type, type, type until he bounced off the far edge, no sense of column width at all. His code was excruciatingly terrible for a lot of reasons, but at least it was easy to spot since it looked just as messy as its structure.
How do you know the width of a standard human isn't determined by 2000 years of people choosing partners that would fit beside them on a cart comfortably.
It gets tiring listening to devs rage about the 80-char limit, then go on to produce code that's basically unreadable because it scrolls way off the screen.
Citation needed.
Hacker News keeps clean discourse by downvoting comments that are not relevant or do not stimulate debate.
I'm also not convinced that 80 chars "happens to line up quite well with the human eyes ability to track horizontal lines of text". It's claimed often, but in the absence of any actual studies, the best you can really say on this is that it is your subjective experience. Mine is different - I find 100-120 columns per line to be eminently more readable.
Until the aforementioned study determines what the average peak readability length of _code_ (which I think is likely to be different from regular text, because the semantic units are different between the two), we'll just have to agree to disagree.
80 columns is a pretty good length for lines of text.
I see no tyranny here.
Frankly, it sounds like numerology, to me.
"Hey! Both these numbers are 80, and they describe closely related dimensions. No way that's a coincidence! The newer one must have been specifically chosen to match the older one."
While it could of course be true, until I see reasonable proof, I'm going to assume that both values were the outcome of fitting a data representation (holes or characters) into a size that was effectively fixed for other reasons (standard card size, commonly available paper and CRT widths).
Especially since IBM later put out 96 column cards.
http://www.throwcase.com/2014/12/21/that-five-monkeys-and-a-...
Coincidentally (or perhaps ironically) the article itself is formatted for ~80 characters per line, not because it's bound by the Hollerith card, but because 80 characters is a good ergonomic width.
Maybe because it was written from a terminal?
And why does my terminal window have a baud rate? Why is it so slow?
In my grade 10 "Data Processing" class (when was the last time you heard someone use the term Data Processing?), we had to use IBM cards with a Sharpie (the card reader was thankfully an optical reader vs a punch card reader) to write programs in BASIC (when BASIC still used line numbers). When we had tests, we had to basically write our programs at our desks on cards, run to the card reader to run and check our results on a printout. It made for some hilariously tedious debugging cycles.
If my memory serves correctly, back in that era, having an 80 column card on your Apple II was something worth bragging about.
Hey, with punched cards you had: a) free confetti, b) gunfire soundtrack.
You were deprived and are in the Nile.
[1] https://www.python.org/dev/peps/pep-0008/#maximum-line-lengt...
The 100-character allowance is for code "maintained exclusively or primarily by a team that can reach agreement on this issue".
~80 characters is a good, readable target, but that's not what we have. For a long time, we've had a militant standardization on <81 characters, even in cases where the results are obviously worse than a long line. I imagine that all of us have read or written code containing a line break that blatantly decreased clarity.
So the question remains: why 80? 80-ish, sure, but why such a fixed standard? I don't know enough history to say if that's down to Hollerith cards, or the consequences of auto-formatters, or something else, but there's a more definite question than "what's a good width" here.
Because 80 is a very good approximation to 80-ish.
[1] http://www.righto.com/2016/05/inside-card-sorters-1920s-data...
I don't think that's true at all. While 80 columns becoming initially common for displays was no doubt a product of the H-card, the fact is that there was reasonably widespread support even fairly early in the pre-GUI PC era for alternatives -- both more and less, but probably most notably in use 132 columns -- for display, printing, etc., and they were used where they offered superior utility. But, outside of a few niches, 80 columns stuck even in the face of alternatives, and the reason it did so was ergonomics.
Once you have the number of rows, you want the number of columns to have a good balance. 80 columns gives you well proportioned characters, where other alternatives e.g. 132 do not. Add that to the historic precedence and you have the makings of a standard.
Teletypes were in common use on the first time-sharing systems, and those were only 72 columns wide. Consider yourself lucky to have those extra 8 characters.
http://www.seasip.info/VintagePC/Images/cga.png
So then you need one more row to separate lines (or live with the occasional joined characters, as CGA did with its 640x200 resolution).
> When the Type 80 sorter was introduced, standard AC power hadn't fully taken over and parts of the United States used DC or 25 Hertz AC.[9] Thus, the sorter needed to handle fifteen different line inputs including unusual ones such as 115V DC or 230V 25 Hertz AC.
[1] https://en.wikipedia.org/wiki/Jacquard_loom
http://infolab.stanford.edu/pub/voy/museum/pictures/display/...
http://vt100.net/docs/tp83/chapter5.html
> 132 column × 14 lines (VT100, VT101, VT125) display
> Allows you a larger format for detailed or spread sheet work so you can preview reports prior to printing. (Note: The advanced video option, which is standard with the VT102 and VT131, provides 132 column × 24 lines display.)
If you're in the bay area, you should go see the IBM 1401 demo; it's cool to see a punched card computer in operation. Demos are Wednesdays and Saturdays; schedule is http://www.computerhistory.org/hours/
They've got contact info on their site: http://www.computerhistory.org/contact/
It may be worth it to send an e-mail to see what you could work out.
http://homepage.cs.uiowa.edu/~jones/cards/history.html
Except for Linux Kernel people (who actually have to work and debug stuff in the builtin 80x24 screen) there is no excuse for not using something bigger
Having to break a line because it's 81 characters and your linter is going to complain is completely and utterly ridiculous
It's 2016. How long since the first IBM PC again?
Yes, it's a tyranny. I don't care if the average is around 80 columns, I care about having a hard limit
My current terminal is 110 chars wide, and that's because I use a bigger font.
If you actually use long/descriptive variable names, you can mentally process much wider text quickly, invalidating the research the "80 character optimization" was based on.
Personally I use a 145 character width, because that fits nicely on my portrait-oriented monitors, with room in both left and right margin for the editor to highlight/mark. 80 character wide limits on a modern project is like an adult riding a "Big Wheel".
I generally have one function call per line for ease of debugging. Nothing worse than having to do a fiddly step in/step out dance when you're trying to think about what's going on. But it's also good for keeping on top of line lengths too.
Which is exactly why all such paradigms are _awful_.
Do you have any defense of that? I'd be interested to read it.
I think every article on coding advice I've read for the last decade favors long and descriptive function/variable names.
But long variable names?!? There is no place for such an abomination under this sun.
You mean field names? A paradigm where you have such a thing is _awful_. Seriously. And this is exactly one of the reasons why it is awful and why it leads to an unreadable and unmaintainable code.
And no, I don't believe you. Making your variable names more descriptive does not make your code less readable. Even when it's not strictly necessary, it's not harmful to comprehension UNLESS you refuse to move from a completely outdated line width.
Some people argue that it takes longer to type and edit. But as we all know, we spend far more time reading than writing code, and modern editors (like vim!) have solved this non-problem anyways.
And, yes, OOP is a filth.
Think about it: there's a reason why human languages are filled with pronouns, because if you use the full name for everything, communication will soon become tedious and it will become actually harder to understand.
Any desire for a long and descriptive name should be tempered with a matching desire for conciseness. Otherwise you end up with names like MaybeUpdateDisplayParameterListForValidation. Throw twenty of these names onto a screen, and I have no idea what the hell is going on: I can't even figure out which names are the same at a glance.
The "break" and "span" terms were familiar from a time when more people knew the Snobol language, which has two frequently useful pattern matching operators: BREAK and SPAN. Snobol's BREAK(S) pattern matching operator matches the input up to but not including the single-character match for any of the characters in set S. The set S delimits or "breaks" the sequence. SPAN(S) matches a sequence of one or more characters from the set S.
strpbrk tries to fit "string" "pointer" and "break" into a symbol that is different in the first six characters. It was once a common linker limitation that only the first six characters of external symbols were stored.
Actually the C function which corresponds to the concept of BREAK is strcspn (complemented span), because this gives the (length of) the range characters up to the first match in the set. That is to say, strcspn could have been called strbrk! Then we would have had strspn and strbrk as a complementing pair. In any case, the strpbrk function points one character past the substring indicated by this function; giving a pointer to the breaking character. I think, the following equivalences hold:
which further supports strbrk as a good name for strcspn.Trivia: break and span appear as functions in the Scheme SRFI 1, by Olin Shrivers [1998]. I think these correspond to the take-while and drop-while in Clojure and imitations thereof like the Emacs Lisp dash library.
http://srfi.schemers.org/srfi-1/srfi-1.html#span
But there's a reason that this sort of name has been left behind in modern APIs.
Short names are not left behind in core languages. For instance, a function that gives the length of a list, string or other sequence is often called length or len, and not length_of_sequence or whatever.
Arc, in which HN is programmed, has reduced "lambda" to "fn". "fn" is the same sort of shortening as using "pbrk" for "pointer to break".
Ruby has shortened "print" to "p".
For the basic core of a language, shortening names is good. When you're reading code, the short names by their very brevity tell you "I'm a thing in the core language, and not some external API to some add-on lib", which also has connotations of "I might be useful in many contexts; it may be worth it to learn about me and remember me".
You do have to admit the slight irony of the shortened string-handling function names in C, given this fact.
When compatibility is a burden, people do work hard to break it.
Anyway, there's a "(2012)" missing on the title, and even that makes the article kinda late to the discussion. By that time, most people already didn't care about the 80 lines limits.
http://www.astrodigital.org/space/stshorse.html
The first railroads in the US and UK standardized fairly quickly on 4'8½", but that's not the only size (even today!). The Great Western Railway, for example, was infamously at a 7' gauge. Even in the US, most railroads in the south converged on a 5' gauge until they shifted to 4'9" (not 4'8½"!) on May 31, 1886. The gauge differences in very early (1820s and 1830s) railways were just as diverse as the coal tramways that proceeded them--which means you basically have every value between 4'6" and 5' as the actual track gauge.
Of course, that belies the fact that your track gauge does not determine what you can stick on a train. That's the loading gauge, and these are nowhere near as consistent. The UIC standard loading gauge in Europe is 3.15 m wide, while the standard US loading gauge is 3.25 wide--and they both share the 4'8½" track gauge. (Note: the actual adherence to these standards, particularly in 100+ year-old railways, is a different matter.)
A couple 14 char class names and some indentation and suddenly everything is a formatting contortion, even if the average content length of a line is well under 80, occasional outliers and moderate indentation (at least 3 or 4 indentation levels are common in object oriented languages from class declaration to control flow) and it's well worth it to use 120 char lines.
(And if you write Java you probably need even more space to handle stuff since class names are often a ridiculous number of words long...)
Outside of programming languages, I also think the 80 char limit is terrible for readable html or html templates.
Sure, you can design your document for a different paper size, but then you have to reconfigure the printer for that size, make sure you have the right paper size loaded in the printer (and change it back afterwards!), get new envelopes in the new size, get new binders...
Similarly, if I read a program wider than 80 characters, I have to resize my terminal window and my Emacs window. When I then switch to working on other programs in the same windows, those programs then tend to be infected by wider-than-80-character lines, unless I remember to resize things back to normal, which in turn perpetuates the problem. So either the applications would have to constantly resize themselves when I switch between files (which seems really annoying) or we could just decide to stick to the standard 80 columns which, as many comments here have pointed out, is a reasonable choice to standardize on even if it's arbitrary.
Should be an option to auto resize or auto wrap
> When I then switch to working on other programs in the same windows, those programs then tend to be infected by wider-than-80-character lines unless I remember to resize things back to normal, which in turn perpetuates the problem.
Why would a program care about what size the window was when you ran it in the past?
> So either the applications would have to constantly resize themselves when I switch between files (which seems really annoying)
Isn't that exactly what a GUI is for?