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.