
Does Column Width of 80 Make Sense in 2018? - psalminen
https://hackernoon.com/does-column-width-of-80-make-sense-in-2018-50c161fbdcf6
======
notacoward
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.

~~~
ezoe
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.)

~~~
class4behavior
This arrangement exists because those are in paper format meant to be printed.

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.

~~~
notacoward
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?

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

But maybe I'm getting old. :)

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

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

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

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

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

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

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

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

------
drcharris
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!

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

IMHO it's not worth it. 80 is ok.

------
pasbesoin
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?

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

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

[https://m.youtube.com/watch?v=wf-BqAjZb8M](https://m.youtube.com/watch?v=wf-
BqAjZb8M)

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

------
jstewartmobile
If it's indented so deep to where " _80 or even 100 is too short_ ", it's time
for some refactoring.

~~~
lokedhs
That depends heavily on the language used.

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.

~~~
jstewartmobile
I juggle most of the mainstream ones (including Clojure), and 80 isn't really
causing any problems for me.

------
handbanana
I find 120 fine at work, I think 100 would be about as low as I’d go. Under
that decreases readability (for me)

------
crystalnewb
We use 120 which seems to work fine even on small screens of about 11 inches.

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

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

~~~
crystalnewb
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?

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

------
Jazgot
It makes sense, especially if you use three sided diff.

------
holografix
No.

