Hacker News Reader

Comment by calamityjake | Hacker News Reader

Yup! Python folks don’t seem to think it’s funny when I call the PEP-8 standard, with its 80-column line limit, “punchcard compliant,” though.

View on HN

Don't forget this part of PEP 8:

> For flowing long blocks of text with fewer structural restrictions (docstrings or comments), the line length should be limited to 72 characters.

Older IBM machines could only read 72 columns of the 80 columns of data. The remaining 8 columns were used to store sorting information, eg, a line number so if the card deck was dropped it could be re-sorted using a mechanical sorter.

There are actually deeper reasons for these limits. Text typically gets broken into multiple columns when it would be over about 70 characters long, because reading long lines is uncomfortable.

Many people talk about the 80 column rule as reflecting some technical limitation due to the antiquated punch cards — but they could certainly have made wider punchcards if they wanted to.

Those who refer to it as a technical limitation are almost certainly wrong.

Remington-Rand released a 90-column punched cards, for example, two years after the famous 80-column IBM card. But IBM equipment dominated the market, and their cards became "standard." https://historyofpunchcards.wordpress.com/2014/03/24/rivalry...

Eg, Univac used the 90-column format. https://en.wikipedia.org/wiki/Punched_card#Powers/Remington_...

FWIW, the recommendation of 72 characters seems much more a programming standard than a general readability standard. For example, quoting from https://www.viget.com/articles/the-line-length-misconception... quoting from "Bringhurst's authoritative The Elements of Typographic Style".

> Anything from 45 to 75 characters is widely-regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal

Code is - text wise - not as dense as prose. There's usually a lot more special characters and white space. I don't think rules for prose apply here.

> Older IBM machines could only read 72 columns of the 80 columns of data.

That applied to the early scientific line, the 70x series, as a side effect of their 36-bit word size — they read each card row into two words. Fortran gave them lasting influence.

(Their earliest commercial computer, the IBM 650, could read 50 columns — any 50, determined by wiring a plugboard, as on pre-computer card processing equipment.)

Ahh, I see. Yes, my experience is with some data format defined in the early 1970s using FORTRAN format statements, almost certainly because of IBM's scientific line.

I'm one of those that sticks with 80x25 because I had decades of it influence me.

I do understand, though, that it's dumb, and wouldn't force it on others.

When I started conforming to it, my code became a lot more concise.

I'd advocate every developer conforms to PEP-8 rules (80-char, nesting limits, etc), at least for a 3-12 month period. They'll be a better developer for it.

That's a great idea. Have an opinion about the standard from experience, not gut feel.

I stick with it because I read the newspaper and eventually discovered that the wider a column is, the harder it is to read. I understand that it's not quite the same with code, and I don't know that there's any significant difference between 79 and 81 columns, but I never found anything that I couldn't get to work with 80 with a few minutes thought, so why not.

Yep. Newspapers are laid out in columns because that's simply easier for people to read.

Since you're into dead tree editions, here's a fun fact you may not know: The fibers in newsprint are aligned vertically so that you can easily tear out an article vertically along its column. Tearing horizontally cleanly is significantly more difficult.

Source: Worked for two major newspaper companies.

Probably vertical for strength too. They need it to be pulled the rollers in the printing machine.

Paper in books is also aligned the same way, to resist better to humidity.

Humidity enlarges the fibres, but doesn't get them longer. In a humid environment a book grows wider but not taller.

If the paper is oriented the other way, the paper would grow taller and the spine of the book, which is stitched and glued, would force the paper to warp and became ondulated.

It lets me have 3-4 columns of code on a standard laptop or 8 columns on a 4k monitor, which is a huge productivity win.

Only about 2.5 for me (at my font size on a 1920×1080 screen), but it's a productivity win regardless, and it's a massive productivity sink when I have to work with code written without that constraint.

An 80+ character line is also a code smell for me; if a statement is so complex that it pushes past the 80 character mark and it can't be split into smaller chunks on their own lines, then I know for sure that something needs refactored (whether it be the statement itself or the nested control structures around it).

Yeah, I actually keep my editor columns at about 65-70 with :set nowrap. I find this gives me appropriate pressure to write shorter lines, but if I go past the end I've got another 10 columns or so until I hit 80.

It's not really dumb. It's good to have somewhat of a standard.

If there's anything wrong with it, it's that it's too big!

Ideally we might have settled on something like newspaper column widths for readability - which are way less than 80.

Except that pep8 doesn't call for 80-column limit?[1] Or am I missing something? It seems pretty clearly to request 79 to me. This is actually one of my pet peeves about pep8, why can't it just be 80 like everyone else?

[1] https://www.python.org/dev/peps/pep-0008/#maximum-line-lengt...

"Because an 80 char wide Emacs window starts wrapping at 79."

https://www.reddit.com/r/learnpython/comments/1h2eug/pep_8_w...

Ugh.

Neat, another weapon to use against emacs in the vim vs emacs war.

Because with a diff annotation, it grows to 80.

huh, that's actually the first time I've heard a somewhat reasonable answer for that question. I wonder why pep8 gives such a terrible reason (editors that show newline chars) when there's actually a somewhat defensible reason. I still disagree with it, and other guides don't appear to consider this a problem even for projects like the linux kernel, which considers terminal users to be first class citizens, but it's at least nice to know a better reasoning than showing newline chars.

Make your editor worry about long lines. In vim:

  set wrap
  set sbr=\

In Visual Studio:

Tools -> Options -> Text Editor -> All Lnaguages. Select word wrap and Show Visual Glyphs.

Fortunately this is a commonly overridable setting in pep8 linters; I generally go with what django project established: 119. The complaints about the odd length really helps identify the engineers who shouldn't be making coding style decisions.

Why is this an invalid complaint? Are they complaining because it's not 120, or because it's significantly larger than 80? 120 means that you can't comfortably split two files on the same monitor (on most monitors), which is a very valid complaint (and is often cited by style guides for various languages as a reason to not exceed 80 chars). If they're complaining that it's 119 instead of 120, then maybe I can see a little bit what you're getting at.

> If they're complaining that it's 119 instead of 120, then maybe I can see a little bit what you're getting at.

This is indeed the complaint. Apologies it wasn't clearer.

Reply on news.ycombinator.com