5 ms·

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 abo

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.

noam_k 3y ago
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-width https://qemu-project.gitlab.io/qemu/devel/style.html#line-wi...
- o11c 3y ago
  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.
PhilipRoman 3y ago
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.
- redman25 3y ago
  Same, mainly because I like a fairly large font size, 17pt. Makes it tough with long line codebases though...
yaantc 3y ago
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 ;)
globular-toast 3y ago
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.
kazinator 3y ago
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.
- 8n4vidtmkvmk 3y ago
  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.
  - kazinator 3y ago
    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.
8n4vidtmkvmk 3y ago
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.

noam_k 3y ago

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-width https://qemu-project.gitlab.io/qemu/devel/style.html#line-wi...

o11c 3y ago
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.

PhilipRoman 3y ago

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.

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

yaantc 3y ago

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 ;)

globular-toast 3y ago

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.

kazinator 3y ago

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.

8n4vidtmkvmk 3y ago
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.
- kazinator 3y ago
  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.

8n4vidtmkvmk 3y ago

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.