80 Characters per Line Is a Standard Worth Sticking to Even Today
nickjanetakis.com
80 Characters per Line Is a Standard Worth Sticking to Even Today
1–10 of 48 posts
Re: 80 Characters per Line Is a Standard Worth Sticking to Even Today
#2You can tear my 120 character line width from my cold dead hands.
Re: 80 Characters per Line Is a Standard Worth Sticking to Even Today
#3This 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.
Re: 80 Characters per Line Is a Standard Worth Sticking to Even Today
#4This 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.
using FooMemo = System.Collections.Immutable.ImmutableSortedDictionary;Re: 80 Characters per Line Is a Standard Worth Sticking to Even Today
#5We 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.
Re: 80 Characters per Line Is a Standard Worth Sticking to Even Today
#6This 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. using FooMemo = System.Collections.Immutable.ImmutableSortedDictionary ;
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.
Re: 80 Characters per Line Is a Standard Worth Sticking to Even Today
#7In 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).
Re: 80 Characters per Line Is a Standard Worth Sticking to Even Today
#8Vscode 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.
Re: 80 Characters per Line Is a Standard Worth Sticking to Even Today
#9In 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 migh…
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?
Re: 80 Characters per Line Is a Standard Worth Sticking to Even Today
#10We 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.