80 Characters per Line Is a Standard Worth Sticking to Even Today(nickjanetakis.com)
nickjanetakis.com
80 Characters per Line Is a Standard Worth Sticking to Even Today
https://nickjanetakis.com/blog/80-characters-per-line-is-a-standard-worth-sticking-to-even-today
47 comments
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.
I have a monitor in portrait to reduce scrolling.
> When you have 80 characters for line, you are wasting a lot of horizontal space on most configurations.
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:
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).
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).
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.
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.
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.
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.
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).
No, if you don't hard-wrap inside lines, then each person can use their own editor with auto-soft-wrap they like.
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.
Anything that makes code review harder or less comfortable is deeply destructive to code quality.
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.
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.
What tabsize do you enforce and how many meetings were it before a number was agreed upon?
Doesn't matter. What matters is consistency in the repo. To this effect, it's important the CI process enforces it - code reviewers could never do it, and it's a waste of their time. I highly recommend auto-formatters like Black, Prettier, Gofmt, etc. They take so much cognitive load off devs and reviewers, it's completely worth it. (In practice, this means whoever sets up the CI process gets to decide :P)
Unified diffs beat side-by-side the majority of the time IMO.
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.
(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.
You can tear my 120 character line width from my cold dead hands.
Cold dead hands won't be writing any more unreviewable code.
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.
C# offers a way to mitigate that, somewhat.
I often have something like this among the top level `using` statements.
I often have something like this among the top level `using` statements.
using FooMemo = System.Collections.Immutable.ImmutableSortedDictionary<string, Foo>;^ Your line of code is 85 characters though.. Would you bother to split this line somewhere? (if trying to conform to an 80char limit)
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>()`.
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.
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 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)
(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)
You can do similar in C++. The problem is when the number of long types and variable names grows, you end up with classes and functions full of `using`, which gets confusing fast.
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.
100 seems like a good modern take to me.
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.
I can only imagine that this would be even more important for individuals with more severe vision impairments.
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).
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).
When I write in Markdown, I generally just turn on soft wrapping in my text editor and just make each paragraph one line.
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.
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.
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?
You seem to be saying that when writing markdown you have no need to refer to anything else?
> 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.
While line lengths may be significant for code, where limiting "sentence length" may be useful, prose is an entirely different thing to read.
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.
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.
There’s empirical evidence to back it up.
The “I have a big monitor” guys just need to stop. Please.
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.)
I prefer Zen Mode, which is similar but with only the file you're editing showing.
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?)
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.
No. 80 is way too narrow. Forget screen size, it's just not enough for a lot of code lines.
Who doesn't use soft line wrapping?
It's not, but good luck ever getting rid of it.
css hack for hn:
p, span{
max-width: 60ch !important;
display:inline-block;
}
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.