
80 Characters per Line Is a Standard Worth Sticking to Even Today - ColinWright
https://nickjanetakis.com/blog/80-characters-per-line-is-a-standard-worth-sticking-to-even-today
======
RcouF1uZ4gsC
The whole analysis of justifying 80 characters per line by talking about how
many more windows you can place side by is problematic. The problem is that
this same logic would suggest that 40 characters per line is even better
because we can get in even more side by side views.

I would like to talk about the downsides of 80 characters.

First point is that most monitor configurations are wider than they are tall.
When you have 80 characters for line, you are wasting a lot of horizontal
space on most configurations. This is especially true with laptops.

Second, at least for me, I am focusing on 1 file most of the time. 90% of the
time, I write code in 1 file, with maybe 10%, I look at 2 files. With wide
lines, I can see more of my code at a glance without scrolling.

Third, when you break at 80 characters, you waste more space cause you need to
indent the new lines that were broken up.

Fourth, if you use languages like Python that have semantic whitespace, you
need line continuation characters that just add to the noise.

Fifth, for those cases where you are comparing code side by side, having an
editor that does intelligent wrapping to make code narrower is not that big of
a deal.

~~~
magduf
Completely agreed. I prefer 100-character lines; with that, I have less line-
breaking, and I can still easily fit two code windows side-by-side on my
widescreen monitors. 120 characters would be good too, but I think anything
over that yields greatly diminishing returns.

~~~
mixmastamyk
I have a monitor in portrait to reduce scrolling.

------
nojvek
Vscode does an autowrap maintaining the indent. So you can have it at any
number.

I don’t get the 80 char width fanatics. I like long lines. I want my editor to
format it based on my screen width.

80 breaks my flow.

~~~
marssaxman
That's great if you are working alone or on a team where everyone agrees on
the same editor with the same auto-wrap feature. In a mixed environment,
writing code that is only readable if people choose the same tools you prefer
can be a bit rude.

~~~
rhn_mk1
That cuts both ways. The most comfortable combo of a display and font size
leaves me at 70 characters per line, making anything more wrap awkwardly. It
wouldn't be a stretch to say that XX-chars limit only works if everyone else
has tools that work best with XX.

~~~
u801e
MIME has the format=flowed option that would handle auto-wrapping text at the
display width. But it requires leaving a trailing whitespace character at the
end of each line that you don't want to hard-wrap (which wouldn't work well
with most code linters without changing their configuration).

------
guitarbill
We also enforce this. Not for personal or aesthetic reasons, but to keep code
reviewers sane and let them review code side-by-side (as many devs do) when
they might not have an ultra-wide monitor available.

~~~
quink
Unified diffs beat side-by-side the majority of the time IMO.

~~~
dkersten
I disagree. I personally find side-by-side easier the majority of the time
(although for some cases, unified is easier, eg when I have a single line with
a word or character changed).

------
skybrian
Whatever you pick, it should be a guideline and not a strict rule, so it
doesn't interfere with automatic edits. Renaming a variable so that it's
slightly longer shouldn't cause cascading changes.

(This is why gofmt doesn't enforce a line limit.)

When a human edits the code, they can fix it if the lines seem too long.

------
ChrisRR
You can tear my 120 character line width from my cold dead hands.

~~~
ncmncm
Cold dead hands won't be writing any more unreviewable code.

~~~
ChrisRR
You can fit 120 characters side-by-side on a 1080 monitor no problem (and I
regularly do)

~~~
elderK
You're assuming everyone is able to read text at the same font size as you.

The font size will likely be increased during a code review, too, depending on
how the code is presented to your team.

------
smt88
This isn't too hard in some languages and I prefer it, but there are other
languages (like C#) where class names are long and descriptive (e.g.
ImmutableSortedDictionary) and it becomes harder to read instead of easier.

~~~
noblethrasher
C# offers a way to mitigate that, somewhat.

I often have something like this among the top level `using` statements.

    
    
        using FooMemo = System.Collections.Immutable.ImmutableSortedDictionary<string, Foo>;

~~~
WorldMaker
Also `var` is such an important mitigatory for this in C# that it continues to
astound me that some of the worst offenders also eschew `var` in C#. You
really don't need the redundancy of `ImmutableSortedDictionary<string, Foo>
localCache = new ImmutableSortedDictionary<string, Foo>()`, it's not some sort
of Prolog assertion where the strict tautology makes different code than `var
localCache = new ImmutableSortedDictionary<string, Foo>()`.

~~~
kstenerud
The problems start when you open code to see

var localcache = cachemaster.cacheFor(foo);

Now you have no idea what it is until you dig into the (hopefully correct) API
docs, or use an IDE that can untangle things.

~~~
guitarbill
I don't buy it. It's one jump to method definition away, which even an editor
without IDE capability should be able to manage. But also, this is what
dynamic languages look like, and people still manage to be productive.

(I'll agree it can be a bit tricky with LINQ and anonymous types in C#, but I
think `var` usage is worth that trade-off)

------
cjbprime
80 vs 120 makes it easy to declare 80 the winner, but I'm less convinced that
80's better than 90 or 100, especially for JS with callbacks. There's simply a
couple extra indentation stops compared to languages like C or Go.

100 seems like a good modern take to me.

------
ThorinJacobs
One reason to suggest a smaller max character count is to assist those with
impaired vision. I'm highly myopic and, while my lenses correct for it, I
still seem to get eyestrain when using the default font/sizes in most IDEs.
Bigger-screen monitors counterintuitively seem to make this worse, not better.

I can only imagine that this would be even more important for individuals with
more severe vision impairments.

------
kevindong
In code, enforcing a max character count per line is debatable and has some
merit.

In prose (i.e. documentation written in Markdown), I'd say that enforcing a
max count is definitely counterproductive. Prose is meant to start a new line
whenever it's needed. What you write in Markdown is not necessarily how it'll
get formatted on a web page (i.e. even if your input is capped at 80
characters per line, the output might not necessarily be capped at 80
characters per line) since display fonts typically aren't monospaced.
Consequently, the text in one line in your .md file will not necessarily show
up as one line in the webpage (in fact, it probably won't).

~~~
ncmncm
Can you explain how any of the above connects to anything else? If the
markdown text will be reformatted for display, you get no benefit from writing
it in a wider format than allows more than one source document to be on the
display at once.

You seem to be saying that when writing markdown you have no need to refer to
anything else?

~~~
rhn_mk1
> you get no benefit from writing it in a wider format

Putting unlimited characters on a line is not merely a "wider format". It's a
way of saying "format it as wide as you like", therefore the benefit is not in
having a wider format, but one that simultaneously wider and narrower,
depending on what's needed.

    
    
      To help visualize the benefit, abolishing line length in
      prose prevents
      lines from breaking in unexpected places, when the user's
      display is
      narrower than the preformatted text line. I find it
      extremely jarring.
    

With almost every editor today being able to word wrap, this stops being a
problem.

While line lengths may be significant for code, where limiting "sentence
length" may be useful, prose is an entirely different thing to read.

------
Roboprog
Textbooks and newspapers print in multiple columns, even when using tabloid
size paper, because it’s more readable.

There’s empirical evidence to back it up.

The “I have a big monitor” guys just need to stop. Please.

~~~
bnolsen
I have a big monitor and fit 4 80 wide terms side by side quite nicely with a
bit of room to spare (34" ultrawide 1440 monitor).

------
WorldMaker
One VS Code suggestion I'd mention is Centered Layout mode (under View >
Appearance). If you only have one editor group open and aren't doing side-by-
side work, it's a nice relaxed view of the editor that defaults to roughly 80
characters as well. (Official docs say it defaults to a golden ratio of your
screen resolution, so it's not directly based on character count.)

~~~
0-_-0
I prefer Zen Mode, which is similar but with only the file you're editing
showing.

~~~
WorldMaker
Also, Both together is a great option. (I think the combo is often but not
always the default now, depending I think on how you enter Zen Mode?)

------
exabrial
I think software is common enough in nearly every editor you not enforce
limits, but instead "one thing at a time" rules.

~~~
spapin
Many lines to do one things, or many things on one line, are what makes code
hard to read. Not the number of letters.

------
zapzupnz
It's a good ideal, but maybe a bit short for some languages like Objective-C
and Swift which use rather wordy function names/selectors; chaining them
across multiple lines for the sake of hitting 80 characters per line can be
much harder to read.

------
sfopdxnonstop
No. 80 is way too narrow. Forget screen size, it's just not enough for a lot
of code lines.

------
cosmopaladin
Who doesn't use soft line wrapping?

------
anth_anm
It's not, but good luck ever getting rid of it.

------
anotheryou
css hack for hn:

    
    
       p, span{
         max-width: 60ch !important;
         display:inline-block; 
       }
    

(probably breaks other sites)

