Hacker News Reader

Comment by benbenolson | Hacker News Reader

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.

View on HN

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!

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.

> it's an accident which happens to line up quite well with the human eyes ability to track horizontal lines of text.

Citation needed.

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.

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

oh my god, you just uncovered the cause of the obesity epidemic in america- the spread of SUVs and wide multi-lane highways

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

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.

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.

I don't think we read code the same way we read normal text. If you have this in your code:

    qry.setParameter("a", a);
    qry.setParameter("b", b);
    qry.setParameter("foo", foo);
    qry.setParameter("bar", bar);

After the first "qry.setParameter" you're no longer reading anything but the parameters and your eyes are moving vertically.

Or if you have something like this:

    Query qry = getEntityManager().createNamedQuery("User.findUserBySomething", Long.class);

You're only reading the "User.findUserBySomething". The rest of it is mainly fluff.

Just for the record, that bit of code gets cut off at ", Long." for me, and then there's a scrollbar. (I always read HN zoomed-in.)

There's a CSS rule constraining the width of <pre> blocks to 600px.

Personally I find that second line annoyingly long and would split it for readability's sake.

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.

Maybe 80 is standard for code. Newspaper may have another ergonomic standard, also bible.

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.

Screenshot of what I mean: http://www.trbimg.com/img-5667d3f6/turbine/la-la-na-menace02...

> We've all got widescreen monitors now, right?

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.

> Plus, this only gets worse as you get older and your eyesight starts to diminish.

Yup, I'm at that point.

80col is narrow for Java because Java has very long method names, explicit tyle declarations, and class names on static methods.

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.

[1]: https://tkware.info/2016/05/08/a-case-for-increasing-pep8-li...

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 other example,

  build_url = "{url}/pipelines/{pipeline}/jobs/{jobname}/builds/{buildname}".format(
      url=os.environ['ATC_EXTERNAL_URL'],
      pipeline=os.environ['BUILD_PIPELINE_NAME'],
      jobname=os.environ['BUILD_JOB_NAME'],
      buildname=os.environ['BUILD_NAME'],
  )

could perhaps be written as

  urltmpl = "{url}/pipelines/{pipeline}/jobs/{jobname}/builds/{buildname}"
  build_url = urltmpl.format(
      ...

or like this:

  build_url = "/".join((os.environ['ATC_EXTERNAL_URL'],
                       "pipelines", os.environ['BUILD_PIPELINE_NAME'],
                       "jobs", os.environ['BUILD_JOB_NAME'],
                       "builds", os.environ['BUILD_NAME']))

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.

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.

Reply on news.ycombinator.com