80 Characters per Line Is a Standard Worth Sticking to Even Today
nickjanetakis.com
nickjanetakis.com
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.
But then you're requiring those who read through your code to have the window displaying your code maximized in order to avoid having it wrap or having to scroll to read it.
> 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.
When viewing diffs, a lot of people like to view them side by side. In some cases, people use a tool like kdiff3 to handle merges and need to be able to see 3 copies of the file side by side.
> Third, when you break at 80 characters, you waste more space cause you need to indent the new lines that were broken up.
It really depends on whether you use a lot of long variable names and/or have to include scope identifiers when referencing them. In python, a typical module may have a very small fraction of statements that require lines greater than 80 characters. That means that it doesn't add that many more lines to the file compared to just keeping those longer statements as a single line.
> Fourth, if you use languages like Python that have semantic whitespace, you need line continuation characters that just add to the noise.
Not necessarily. Any opening (, [, { can effectively serve as a continuation character. So you could write a print statement like:
print(
'Hello there. '
'This will be printed on a single line.'
)
For line based diffs, it does make the diff significantly harder to read in my experience (especially when looking at the source file in conjunction with the diff).
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.
It is entirely hard enough to get people to do meaningful review without kneecapping them by obliging them to side-scroll just to see what changed.
(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.
The font size will likely be increased during a code review, too, depending on how the code is presented to your team.
I often have something like this among the top level `using` statements.
using FooMemo = System.Collections.Immutable.ImmutableSortedDictionary<string, Foo>;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.
(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)
100 seems like a good modern take to me.
I can only imagine that this would be even more important for individuals with more severe vision impairments.
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).
Editing plain text using my favorite font, Bistream Vera Sans Mono 12, on a 1920x1080 display, lines break about the 150th column. That width seems to work reasonably well for me when writing blog posts.
You seem to be saying that when writing markdown you have no need to refer to anything else?
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.
While line lengths may be significant for code, where limiting "sentence length" may be useful, prose is an entirely different thing to read.
There’s empirical evidence to back it up.
The “I have a big monitor” guys just need to stop. Please.
p, span{
max-width: 60ch !important;
display:inline-block;
}