Hacker News Reader

Comment by xwowsersx | Hacker News Reader

So speaking of line widths, I'm curious what people generally use for programming and enforce with auto-formatters. I know there tends to be a lot of debate about this wholly subjective question, but I'm wondering what reasoning people have for their preferred line length. It seems many tools still default to 80 characters. This does feel restrictive, but, on the other hand, I personally find shorter line lengths to be quite pleasant. Still 80 feels too restrictive and I think its being a default is just a historical accident, right (punch cards and early monitors/terminals)? Anyhow, just curious if there's any interesting reasoning to prefer one limit over another or if it all comes down to personal aesthetic preferences.

View on HN

My preference is 100 characters. I find it usually takes up half the screen, allowing split screen editing (on modern screen sizes).

But while on the subject, I can't help bringing up the QEMU coding style[0]:

> Some people like to tile their 24” screens with a 6x4 matrix of 80x24 xterms and use vi in all of them. The best way to punish them is to let them keep doing it.

[0]: https://qemu-project.gitlab.io/qemu/devel/style.html#line-wi...

That's a silly quote. Everybody knows it's only a vector since a tall 80x84 or whatever is always useful for keeping more of the file on the screen.

Also, for reference, a table of font sizes and number of terminals beside each other that fit on a given size screen:

            1t      2t      3t      4t      5t      6t
    6px     480     960     1440    1920    2400    2880
    7px     560     1120    1680    2240    2800    3360
    8px     640     1280    1920    2560    3200    3840
    9px     720     1440    2160    2880    3600    4320
    10px    800     1600    2400    3200    4000    4800
    12px    960     1920    2880    3840    4800    5760
    14px    1120    2240    3360    4480    5600    6720
    16px    1280    2560    3840    5120    6400    7680

On a screen with the traditional ~100 DPI, a 6px wide font is quite readable so on 1920x1080 you get exactly 4 columns of terminals (just beware window decorations trying to steal extra pixels). If the height is 13px (so it's about a 9.5pt font IF point size is measured honestly) you get about 75 lines depending on taskbar and window headers.

I stick to 80 columns, as with it I can better use my screen space. Even on modern wide screens.

Even if some lines are long, a lot of lines are short. So the end-of-line side of a text editor is less densely used than the start of line side. This may not show too much with 80 columns line, but with longer lines one can notice that the end-of-line space is mostly blank, with low information density.

So instead of using long lines, I'm using 80 columns lines but with several (3 in practice) text panes in parallel. Basically, my work set-up is 3 columns of text panes, with 80 columns of characters each. That allows working on a module body with its header still visible, and the header of another used module shown too. Or to see two different parts of the same file easily (head with declaration, bottom with code). In other words, it's easy to find productive use for 3 parallel text panes. And each one is "information dense".

I'd like to have a little more than 80 columns. 100 would be a good number (higher waste space on the EOL side). But with this I can't fit 3 parallel panes on some screen. So I stick with 80 characters, which is OK too. 80 characters can be annoying when manually formatting code, but when using an automatic formatter (clang-format, yapf, black...) it's not such a big deal.

Anyway, there's a big subjective part in this so just use what's fine by you (and your team). Still, the information density part is an objective thing. So if you can use 3 parallel text panes with your editor, I suggest you try it. That may make you stick to 80 chars too, and not only for historical reasons ;)

The maximum width of a line from the first printing character to the last should be limited to about 40 characters.

The absolute line length should not be subject to a hard limit.

This is because code indents:

  ------
    -----
    -----
      ------
        ------
          ------

What I don't want to be obnoxiously long is any of the ----- content itself, regardless of how much or how little indentation is in front of it.

I don't like ridiculous nesting, but imposing some hard limit like 80 columns or 100 is counterproductive; let that naturally limit itself.

When confronted with these limits, programmers do ugly things, like start using shorter and shorter lines at deeper nesting levels, those lines being awkwardly split to fit:

             fun(arg,   // 80th column here
                 arg,   //
                 term + //
                 term + //
                 term); //

Please, just go over 80 and write fun(arg, arg, term + term + term)!

The counterargument is that if you ever have to produce hard copy, it's good if the code sticks to reasonable number of columns. I think we are past the era where people bring hardcopies of code to code reviews, though. We also care about code histories a lot more; printing out a program on paper is no longer considered a viable way to preserve it for future generations, since it loses the change history.

Forcing people to split their function into subfunctions to reduce nesting usually works well. Occasionally I'm reluctant to do so, but whenever I do, the code seems to get better. Obviously don't take it to the extreme but if you're 5 levels deep already there's probably a nicer way to write that.

Helper functions that are called only once can easily make the logic harder to read than the original function. Now you have to jump around through detours to recover the linear flow. If the functions aren't inlined, it can slow things down for the machine too.

I like the approach of aiming for ~80 chars, allowing ~88 chars but not being anal about it and allowing judicious use of disabling rules on a per-line basis.

This seems common in Python using a combination of black to do the formatting and flake8 to enforce it. It works well in almost all cases. I've not encountered many situations where one could argue >88 chars leads to the most readable code.

I like 120 or so but I give 0 shits if my personal code gets very wide. At work they force 80 and normally that's fine but every now and then it produces some gnarly code and I just LOL at whoever has to review it because I have 0 patience for Fighting against the auto formatter and or style committee. They created this mess, they can live with it.

I still like 80 as it is just perfect to be able to see two split diffs simultaneously on my screen without any line wrapping whatsoever (in a roughly 350 column terminal) which is a pretty common use case for me.

Same, mainly because I like a fairly large font size, 17pt. Makes it tough with long line codebases though...

Reply on news.ycombinator.com