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.
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.
> 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:
print(
'Hello there. '
'This will be printed on a single line.'
)
> 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.
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).
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).
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.
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)
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).
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 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.
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.
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>()`.
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)
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.
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.
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).
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.
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 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.
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.)
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.
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.