120 on an 11 inch screen might be highly eyesight-dependent, especially if there is anything else on the screen at the same time. Not everyone worth hiring in the industry has optimal vision.
I just checked. I have a 17 inch laptop screen (uncommon and has to be sought for these days). To hit 120 characters on two terminals side-by-side requires 9pt font. That's definitely not something everyone can manage.
I think 120 might even be pushing the limits of conscientiousness.
I was speaking of lines of code in a full screen text editor, I'm sure there are many programs that when displayed side by side on a small screen 120 chars would be too many. But let's avoid the strawman here. So 2 terminals side by side 120 chars each, you tried to display 240 per line in actuality? Do i have it right?
Not a straw man - on a laptop away from readily available external monitors, it's quite common to want to see two things at once while doing work. We're discussing the line length policy for a single line of source code in a single file, not the number of characters that can visibly fit side by side on a screen.
There's definitely a bit more flexibility - not infinite - when you only consider the full-scale case. But one is often less productive with that as the only viable option, or else one has external monitors in which case in that usage pattern the laptop is effectively a desktop.
Possibly for weight reasons? I'm in my early to mid 30s with decent near-distance eyesight, but adding my Dell 12.5" ultrabook to other things I routinely need to carry is increasingly starting to hurt. My next laptop bag will probably be a backpack to mitigate that, but it still doesn't make weight irrelevant.
Anyway, one doesn't have to go to that extent to make the point: as per the sibling reply from d_, even on a 17 inch monitor one can have issues with 120-character lines if viewing two files side by side (or 50% browser 50% editor).
Hit the weight room, a 30 yo human should be able to carry at least 30 lbs with no problem for a few miles. My daily driver is a P51. You might also consider on of the pieces of luggage with wheels and an extendo handle.
You'll be missing out on a lot of good colleagues if you set your policies based only on what works for young healthy in-shape people with the dominant tech industry locations and lifestyles.
Yes, I self limit to between 80 and 90 characters. Diffs can get hairy once you start routinely going over 100 characters. Also, it helps force me to limit complexity in my subroutines. In my opinion, using 120 characters is a smell that you're trying to do too much in a single line.
With my current 1440p screen the only way I can keep two files open side to side without going blind is to limit myself to 80 characters, the screen linked in the article is 1080p and they propose to keep three files open at 120 column width? That won't really work for me.
I'm 48, and I'm starting to crank up font sizes on my monitors. I can jam lots of tiny font on my monitor if I wear reading glasses, but I then end up much closer to the screen than I'd like.
Yes, because you can split IDE tabs within the IDE still. 120 may be good too with increased resolutions but I like to keep my IDE on the same monitor.
In three different companies across three countries within the last decade I've seen development teams all settle on a 120 character limit with no protest from anyone. And this is a very good thing: it allows for descriptive names (extremely helpful for readability) and avoids unnatural line breaks such as within a comparison expression.
Most lines are like 20-30 characters wide, no matter the limit. So the wasted space will be almost the same, no matter the limit.
On the other hand with 120 limit every once in a while you have to read very long line, and with merge tools or big fonts you can have problems and have to scroll.
I have a few reasons why I still think 80 characters is a great limit.
Readability. It's difficult enough to read through long lines of normal text on a badly formatted website.
Naming. I could go on about this one. Namespacing was created for a reason, don't write any long names. This most often will make your code considerably shorter.
Formatting. If you have short names and you're still ending up will the long lines, you need to understand how to format your code properly.
Did you ever wonder why magazines and newspapers use multiple columns? Because it's easier to read. When lines get too wide, it becomes harder to scan from the end of one line to the beginning of the next. There's solid science behind that, based on both physiology and observation of effects. For text, the recommendation is generally as low as 50 characters or as high as 75. Yes, reading code is a bit different, but not so much different that the same principles don't apply.
80 wasn't chosen, or kept so long, arbitrarily. To overcome the issues with both readability and ability to support side-by-side diffs or multiple files on smaller monitors or for those with poorer eyesight, there'd have to be a supportable positive reason to go higher. So far all I've seen is personal preference and occasionally support of bad habits (e.g. "trying to do too much in a single line" as another commenter put it). I just don't find that very convincing.
As a generation who read text in flow layout from the start, multiple columns fixed layout is quite ugly, hard to read, shall be abolished from the world(especially academic world.)
Why does it matter? Does the physiology of the human eye change when we're looking at a screen instead of paper? What is it about screens that suddenly makes it easier to saccade back to the beginning of the next line?
Exactly - there's a good reason why this article, arguing that we have huge monitors now, is still constrained to a max-width that takes up 28% of my screen's width. And it's not because we're still designing for an 800x600 constraint.
If you have wide lines containing a lot of content, increasing the line spacing (or, leading) can help somewhat in readability. Unfortunately, terminals and editors don't always make this easy. Certainly not as easy as changing their display width.
You burn some vertical room -- all the more apparent with today's widescreen trend. But when you're trying to keep the strain from driving you crazy when reading a bunch of adjacent wide lines, it can help.
Also, other visual differentiators. Remember the old, wide band-printer reports, done on paper that varied background color every 5 lines or similar?
Even when coding,splitting the IDE screen helps read the same code file better (each split screen showing a segment of the code). People split terminal screens using tmux and the like as well.
I think there is a solid argument for not consuming the entire column count of a screen,not sure if that's 80 though.
In Lisp you can have code blocks that are clearly independent units hanging 50 characters off to the right. A limit of 80 would limit the lines in the code block to 30 characters, which is not enough. Lisp tends to have pretty long function names, like multiple-value-bind or with-open-file.
For me, the primary argument of limiting column width is a very different one: If your code is very wide, you're probably doing something wrong, which means you should refactor your code
This "something" includes:
- Deeply indented (= nested) code
- Very large numbers of function arguments
- Overly-verbose naming
- The Train Wreck anti pattern
In my experience, 80 is indeed a bit limiting, especially in languages where you're basically forced to start 3 or 4 indentation levels deep, but anything beyond 120ish is usually a sign that you're doing something wrong.
The 80 char limit was, IIRC, based around the capabilities of fixed-width terminals and dot-matrix printers. It's not magical.
I have the luxury of writing code only for myself, so I can maximise devotion to my 'personal style' and not worry about other people's opinions.
I'm all about information density, and since on 99.9% of monitors the vertical axis is the short one, and the horizontal axis is the long one, I want to save as much vertical space as possible. This is also why I can't stand horizontal tabs (thank you, Tree Style Tab).
On a 27" 4K monitor I get two side-by-side files open in my IDE, with a 10-point font, at 160 char wrap, with vertical tabs. This fits my style because I favour inline comments which maximises my use of the vertical space by not needing another line.
Luckily my eyes are still good enough to read this!
in the python world, i really like Raymond Hettinger’s talk “beyond pep8”, in which he advocates “90-ish” as a line width to shoot for, rather than a slavish fetishism for 80.
This especially matters when you start doing dumb things to codebases like 1-space indents, abbreviated variable names, etc. for the sole purpose of making a linter shut up.
> This especially matters when you start doing dumb things to codebases like 1-space indents
Too-small indents are bad for many of the same reasons as too-long lines, only even more so. The main argument in favor seems to be the desire to cram as much as possible into each line, which is a code smell of the first order. The main argument against (which I find much more compelling) is that it becomes really hard to match up the indentation levels to see the true structure of code without artificial aids. Besides being ugly, those faint vertical lines won't be there in every situation, such as when you're looking at code in a review tool or in gdb or a "primitive" editor while you scramble to fix a problem on a production machine that doesn't (and shouldn't) have your favorite heavyweight IDE installed. Ergonomics matters, and it's about more than personal preference.
I generally aim for 80, but if that starts to get ugly I widen my terminal to 132, which I argue does not revoke my old school credentials because we had 132 column terminals in the old days (VT100, DECWriter II LA36).
Just found this provocative post on HN (the other HN). The interesting part is that it comes from a Java programmer. When I was writing Java and using big IDEs myself, I was too advocating for longer lines.
And now? Now I'm all Vim for 3 years, and 80 char limitation never made more sense than now! Being able to split your screen whichever way you want and still read the code is precious.
39 comments
[ 2.7 ms ] story [ 91.2 ms ] threadI think 120 might even be pushing the limits of conscientiousness.
There's definitely a bit more flexibility - not infinite - when you only consider the full-scale case. But one is often less productive with that as the only viable option, or else one has external monitors in which case in that usage pattern the laptop is effectively a desktop.
The real fallacy is in denigrating the side-by-side workflow. Just having every window be fullscreen would be madness.
Anyway, one doesn't have to go to that extent to make the point: as per the sibling reply from d_, even on a 17 inch monitor one can have issues with 120-character lines if viewing two files side by side (or 50% browser 50% editor).
But maybe I'm getting old. :)
On the other hand with 120 limit every once in a while you have to read very long line, and with merge tools or big fonts you can have problems and have to scroll.
IMHO it's not worth it. 80 is ok.
Readability. It's difficult enough to read through long lines of normal text on a badly formatted website.
Naming. I could go on about this one. Namespacing was created for a reason, don't write any long names. This most often will make your code considerably shorter.
Formatting. If you have short names and you're still ending up will the long lines, you need to understand how to format your code properly.
80 wasn't chosen, or kept so long, arbitrarily. To overcome the issues with both readability and ability to support side-by-side diffs or multiple files on smaller monitors or for those with poorer eyesight, there'd have to be a supportable positive reason to go higher. So far all I've seen is personal preference and occasionally support of bad habits (e.g. "trying to do too much in a single line" as another commenter put it). I just don't find that very convincing.
The argument in favor of narrow-width columns still stands. But we do indeed need to acknowledge that most people read on digital devices now.
You burn some vertical room -- all the more apparent with today's widescreen trend. But when you're trying to keep the strain from driving you crazy when reading a bunch of adjacent wide lines, it can help.
Also, other visual differentiators. Remember the old, wide band-printer reports, done on paper that varied background color every 5 lines or similar?
I think there is a solid argument for not consuming the entire column count of a screen,not sure if that's 80 though.
In Lisp you can have code blocks that are clearly independent units hanging 50 characters off to the right. A limit of 80 would limit the lines in the code block to 30 characters, which is not enough. Lisp tends to have pretty long function names, like multiple-value-bind or with-open-file.
This "something" includes:
- Deeply indented (= nested) code
- Very large numbers of function arguments
- Overly-verbose naming
- The Train Wreck anti pattern
In my experience, 80 is indeed a bit limiting, especially in languages where you're basically forced to start 3 or 4 indentation levels deep, but anything beyond 120ish is usually a sign that you're doing something wrong.
I have the luxury of writing code only for myself, so I can maximise devotion to my 'personal style' and not worry about other people's opinions.
I'm all about information density, and since on 99.9% of monitors the vertical axis is the short one, and the horizontal axis is the long one, I want to save as much vertical space as possible. This is also why I can't stand horizontal tabs (thank you, Tree Style Tab).
On a 27" 4K monitor I get two side-by-side files open in my IDE, with a 10-point font, at 160 char wrap, with vertical tabs. This fits my style because I favour inline comments which maximises my use of the vertical space by not needing another line.
Luckily my eyes are still good enough to read this!
This especially matters when you start doing dumb things to codebases like 1-space indents, abbreviated variable names, etc. for the sole purpose of making a linter shut up.
https://m.youtube.com/watch?v=wf-BqAjZb8M
Too-small indents are bad for many of the same reasons as too-long lines, only even more so. The main argument in favor seems to be the desire to cram as much as possible into each line, which is a code smell of the first order. The main argument against (which I find much more compelling) is that it becomes really hard to match up the indentation levels to see the true structure of code without artificial aids. Besides being ugly, those faint vertical lines won't be there in every situation, such as when you're looking at code in a review tool or in gdb or a "primitive" editor while you scramble to fix a problem on a production machine that doesn't (and shouldn't) have your favorite heavyweight IDE installed. Ergonomics matters, and it's about more than personal preference.