80 characters is way, way too short. I think 120 is a decent spot for today's displays, although I don't mind even longer than that either.
The penultimate paragraph of the article really shows its age.
When there are unclear or conflicting rules ... [y]ou can end up with hilarious games like formatting tennis ...
In the case of Prettier, bikeshedding can still happen over the .prettierrc file, but it's not hard to make an argument for using the default configuration.
Formatters are something I miss whenever using languages without a widely-used formatting tool. For instance, in Common Lisp, code formatting is "whatever Emacs does when formatting the whole buffer". Depending on the exact package used (e.g. SLIME or SLY), the results of formatting the whole buffer may differ. Contrast this to languages like Go where there is one tool (gofmt) and it exposes no configuration, so there is no possibility of bikeshedding over code formatting.
In new projects I usually add an empty .prettierrc file with a single comment:
// Empty file. Use default Prettier settings. No rules here.
Maybe even add a CI step that closes PRs if someone modifies formatter config files.
One minor advantage which wasn’t so relevant in 2008: 80 character lines are much easier to read on a smartphone. This is especially true for Safari on iOS, which always seems to make bad wrapping / sizing decisions with plain text.
ETA: thinking back on it, several years ago I switched from 120 characters to 80 specifically because of this. I don’t have a car, so I read a lot of code on my phone while taking public transit.
Took me a second to realize ETA was "edited to add." I was very confused on what an estimated time of arrival meant, here. :)
I'm surprised reading on a phone is common. Not at all something I would want to do. I'm assuming largely read only there?
Makes me curious if the CWEB idea of styling specifically for reading has extra merit in that flow?
I've made edits to config files on the GitHub mobile app while on-call. Not something I like doing but I like having the option.
I've been reading books on phone since palm pilot and 160x160 screen.
I do not want to type / create on my phone though, certainly not code, or even sign up for stuff / submit / do applications on phone. Makes me a rarity though.
I don’t know how “common” it is, but (like I said in my comment) the only reason I read code on my phone is that I am often on a bus or a subway. The comment about assuming I only read on my phone is bizarre: you are putting words in my mouth for reasons I do not understand. When it comes to books I like paper, and I usually read long PDFs on a tablet.
GP was not assuming you read only on the phone screen, but that you use phone just (only) for reading ("read-only") and not for editing.
Someone else is going to be weird and want to look this up so I'll save you the trouble.
Yes, aithrowawaycomm's claim about line lengths are supported by many, many different sources who recommend a 50 to 80 character line length.
https://duckduckgo.com/?q=reading+optimal+line+length
IMHO, 80 characters is too narrow, especially with Python, for most coding tasks so I settle more around 100 (+-20) characters. PEP-8 says up to 99 characters is okay.
It's worth noting that most of those studies are for body text. To make that more directly applicable we should exclude indentation, but the additional punctuation (especially commas, but unfortunately no parentheses) also affects it.
Shading lines can also improve readability (this is known; the rest of this comment is speculation). It's probably not enough to simply alternating between e.g. white and off-white background, unlike for tables. More likely an alternation between 3 or 4 subtly-different colors is best; maybe these can form a pattern across additional lines (e.g. 121312321). If the difference isn't subtle enough, editing will suffer whenever you break the line count, but for reference only the human eye is pretty good at aligning subtle things. Maybe even an outright paper-texture background image? (This is more often a gimmick, but it can be useful.)
I maintain 80 characters in order to edit files side by side on a laptop screen without side scrolling. I seem to grok code better vertically too.
I love how everytime this debate comes up, the 80 character gang keeps adding more stuff to put side by side.
Now we're shrinking the resolution/sizes of the devices we are using to justify it...
For Python source code, where indentation is significant, I'm convinced that long lines should never be broken early. It should be the IDE's job to (optionally) fold long lines dynamically to the width of a viewer's editor.
If someone breaks a statement early at 72, or 79, or 99 characters (PEP8 recommendations), indentation no longer represents the structure of the program, it now represents the style of the author. Everyone who uses a wider screen suffers.
But if the IDE knows how to fold long lines dynamically, then any reader can use any width screen for viewing and editing. And users may choose not to enable folding at all, so that indentation exclusively represents program structure.
Sticking with 80 characters has been great for my team. Not only does it encourage shorter lines, but comparing diffs on GitHub ensures that both old and new comparisons fit evenly on the page without any cutoffs or wrapping
> formatting tennis
That's a paddling.
Seriously, professionals do this? If someone else wrote it and it does what it is supposed to do, it is not, NOT (no apologies for shouty emphasis), my job to change that.
(I hate tabs, but will never :retab someone else's code.)
My job is either/both to fix bugs and add new capabilities, not to be precious about, well, anything.
I would have serious reservations about any team member who wasted all our time on that.
Consistency makes it easier to compare apples to apples and oranges to oranges.
Just like you don't want to allow both underscore_split, camelCase and TitleCase names in a single JSON object (or even different JSON objects returned by the same API), you might want more consistency overall to exactly avoid people's editors rewriting code someone else did (eg. you edit a module and your editor reformats the entire file).
Well I just want to fix the bug or write the feature and move on, but some want other things from their code.
I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions. I think an autoformatter with the config checked into git is a nice way around this.
> an autoformatter with the config checked into git is a nice way around this.
Yes. At my job we mainly use defaults of rustfmt in most repos. Some repos have .cargo/rustfmt.toml in them. And the neat thing is that cargo picks up this automatically so there’s no per-repo config you have to do after cloning those repos in order to follow repo-specific formatting rules.
In CI we have a step that runs
cargo fmt --all --check
In order then to get your changes merged, you have to follow the same formatting rules that are already in use. Which in turn is as simple as having
cargo fmt --all
It’s nice and easy to set up, and it means that every Rust source file within each individual repo follow the same formatting as the other Rust source files in that same repo.
I don’t particularly care about what specific formatting rules each repo owner chose. (And the vast majority of our repos just use the defaults anyway.) All I care about when I’m working on code is that there is some kind of consistent formatting across the files in the project, and that formatting changes between commits from different people are kept to a minimum so that git log and git blame gives the info that you are interested in. So for me I am very happy that they do it this way at my job.
This approach comes with the benefit of automatically fixing those who simply don't realize their editor's settings disagreed with/didn't pick up on the conventions the project follows.
> I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions.
...it occurs to me, this feels like you're conforming to the tool instead of the other way around.
Is there a reason git blame doesn't have an "ignore whitespace" option? Is it harder than it seems?
I would think the issue is that if you format someone else's code, gitblame then sees you editing that code? Unless you can mark that commit as white space changes only somehow
At home, if I put VS code on my 1080p 24" vertical monitor, I can see about 100 columns (at a reasonable font size, with the VS code sidebar up). I find that to be a little limiting at times but not too bad, and I can close the sidebar to get to 120 columns. Minor issues with horizontal character count are definitely worth it for the massive vertical space though (about 100 lines of code). I've been thinking about replacing it with a 27" 1440p monitor to get a few extra inches of monitor width at about the same pixel density.
I think 110 is a nice spot. You can still split screen but also fit a lot of content on one line
Honestly it depends of the language you're writing in too.
Some language are just long and wordy and having a 'fixed' size just leads to awkward line splits. e.g. all the languages that tend to favour 2 space tabs.
I think the answer is pretty clearly "no, but" (or "yes, if"). Of course it depends on what you're doing – if you're writing shell scripts, it might make sense to keep them at 80 characters in case you have to go down to the data center and edit them from a terminal because your network card failed. But for most code, there's no particular limit that makes sense (in my opinion).
I'm somewhat against code formatting "rules" in general. If it's about readability (/aesthetics), different code will have different properties that make it readable or unreadable. Sometimes, forcing a line break makes code less readable. In other situations, it can have the opposite effect. IMHO, it's a local decision – and the human that's working on that code is better at deciding what's readable than a linter is.
I agree with you that writing readable and aesthetically pleasing code is more art than science (that can be expressed with deterministic rules), I still find some of the rules and rule-checkers beneficial (though I dislike strict formatters).
As such, 80 is as good a limit as any, and makes you think carefully about avoiding deep nesting of blocks, which is usually a good idea anyway. It also allows putting many windows side-by-side on a modern big 4k screen.
I have to push back here a little bit. It really depends.
I mainly use Scala, and I think the majority of Scala code would be far less readable if forced to 80 columns, than if it were a larger number (or simply unconstrained).
My WFH monitor is an Apple Thunderbolt Display, which is woefully out-of-date now. Even on this display, and even though I use a much larger font than most people (16pt Hasklig), and even with a generous project/navigation/etc sidebar, I still get 180 characters. The display I have in the office is even wider, but I can't measure it right now because I'm not there.
My point is, displays are now wide enough where arbitrary line limits don't make sense. Nobody is going to cram stuff into one line unnecessarily, so just leave it up to the local decision about what makes the code most readable. If for some reason a 240-character line is more readable in some situation, then we should talk about that situation rather than why they didn't break the lines.
With 180 characters on your display and lines of more than 90 characters, you can't put two code windows side-by-side.
But it sure depends on the language too, though I wonder what's so peculiar about Scala to really benefit from long lines?
> This is because, back in the bad old days, most computer terminals could only display 25 rows of 80 columns of text on screen at once.
And this is because, back in the super old days, most computers used punched cards. Which had 80 columns.
I have a line length limit I personally stick with, because it works for the display setup I have. But - I don't actually care all that much! I have truncate-lines off, word wrap mode on - or whatever the text editor calls it - so I never miss anything. You could do this too, and now the question of the character line limit becomes much less relevant.
Does it help readability? Sometimes a long line is crappy, and sometimes breaking it up is terrible. I HATE how my python looks after pep-8 gets ahold of it. Before Go, I was team 120-ish instead of 80 as it tends to not break as many otherwise legible lines. After Go, I removed my 120 char ruler in my editor.
yes, for split screen - e.g. two files open at once.
I've got five files open on my monitor right now, side-by-side! Wouldn't be practical if the codebase used a lot of long lines.
Two files on a laptop
It's mentioned in the article..
Yes. Vertical splits.
100 chars is the sweet spot for me. It allows you to have 2 files opened side-by-side in 1080p screen resolutions and even better for 2k res. 24"/27" monitors are the new standards.
I think 100 characters is called to replace the traditional 80 characters rule.
I use 120 or 132 (no idea why I picked that number), but I tend to break my lines well before that, especially on function signatures.
I'm that git that puts each param on a separate line (so I can quickly comment them out when I need to). It annoys other programmers, but once I explain why ...
They're still annoyed, but at least they're quiet about it.
Some old "dumb" terminals could be switched into 132-column mode, this corresponded to the 132 columns on the line printers that printed on wide fan-fold green-bar paper.
The 80 column standard goes back to the 80 columns on a standard IBM punch card.
> I'm that git that puts each param on a separate line
I do that too :)
If you're that git that makes one param per line a standard that you can flunk code review for not adhering to, I'd seriously consider switching jobs were I under you.
65-80 for readability however once you introduce indentation this naturally increases. I always felt that shorter lines were a good way to encourage less nested code. Alas after all these years the consensus is against me.
I still like 80 columns even on modern hardware and displays. It encourages me to keep my lines tidy and to break long lines apart. Sometimes I go a little over, but it's a nice target to reach for.
i'm with you
Short answer - it is not.