I write and prefer code that fits within 80 columns in curl and other projects – and there are reasons for it. I’m a little bored by the people who respond and say that they have 400 inch monitors already and they can use them.
I too have multiple large high resolution screens – but writing wide code is still a bad idea! So I decided I’ll write down my reasoning once and for all!
Narrower is easier to read
There’s a reason newspapers and magazines have used narrow texts for centuries and in fact even books aren’t using long lines. For most humans, it is simply easier on the eyes and brain to read texts that aren’t using really long lines. This has been known for a very long time.
Easy-to-read code is easier to follow and understand which leads to fewer bugs and faster debugging.
Side-by-side works better
I never run windows full sized on my screens for anything except watching movies. I frequently have two or more editor windows next to each other, sometimes also with one or two extra terminal/debugger windows next to those. To make this feasible and still have the code readable, it needs to fit “wrapless” in those windows.
Sometimes reading a code diff is easier side-by-side and then too it is important that the two can fit next to each other nicely.
Better diffs
Having code grow vertically rather than horizontally is beneficial for diff, git and other tools that work on changes to files. It reduces the risk of merge conflicts and it makes the merge conflicts that still happen easier to deal with.
It encourages shorter names
A side effect by strictly not allowing anything beyond column 80 is that it becomes really hard to use those terribly annoying 30+ letters java-style names on functions and identifiers. A function name, and especially local ones, should be short. Having long names make them really hard to read and makes it really hard to spot the difference between the other functions with similarly long names where just a sub-word within is changed.
I know especially Java people object to this as they’re trained in a different culture and say that a method name should rather include a lot of details of the functionality “to help the user”, but to me that’s a weak argument as all non-trivial functions will have more functionality than what can be expressed in the name and thus the user needs to know how the function works anyway.
I don’t mean 2-letter names. I mean long enough to make sense but not be ridiculous lengths. Usually within 15 letters or so.
Just a few spaces per indent level
To make this work, and yet allow a few indent levels, the code basically have to have small indent-levels, so I prefer to have it set to two spaces per level.
Many indent levels is wrong anyway
If you do a lot of indent levels it gets really hard to write code that still fits within the 80 column limit. That’s a subtle way to suggest that you should not write functions that needs or uses that many indent levels. It should then rather be split out into multiple smaller functions, where then each function won’t need that many levels!
Why exactly 80?
Once upon the time it was of course because terminals had that limit and these days the exact number 80 is not a must. I just happen to think that the limit has worked fine in the past and I haven’t found any compelling reason to change it since.
It also has to be a hard and fixed limit as if we allow a few places to go beyond the limit we end up on a slippery slope and code slowly grow wider over time – I’ve seen it happen in many projects with “soft enforcement” on code column limits.
Enforced by a tool
In curl, we have ‘checksrc’ which will yell errors at any user trying to build code with a too long line present. This is good because then we don’t have to “waste” human efforts to point this out to contributors who offer pull requests. The tool will point out such mistakes with ruthless accuracy.
Credits
Image by piotr kurpaska from Pixabay
My rule of thumb has been to try to stop by 74 chars (because one number is as good as another, so why not use one that lets me copy-paste code into email?) but my editors have a hard stop at 100. Of course, different projects have different standards and requirements, so it’s configurable.
Also, some of my monitors are in portrait, for documentation purposes, so narrower code helps there, too.
I’m so tired of everyone pushing for 80 characters like it’s 1970.
> Narrower is easier to read
That’s why word-wrap exists. Everyone can choose their preferred width.
> Side-by-side works better
You can still view code side-by-side when it’s 120 characters wide
> It encourages shorter names
More like, it discourages descriptive names. Now instead of calling it “unit_position_vector” it’s called “upv” so it will fit on the line, and it makes reading the codebase that much harder.
> Just a few spaces per indent level / Many indent levels is wrong anyway
True, but that’s irrelevant to the column width.
> we end up on a slippery slope and code slowly grow wider over time
Ah, yes, the slippery slope of gradually finding the best width.
According to these arguments, we might as well make it 40 characters, to achieve the best code with the fewest indents, shortest names, and least diff collisions.
Or maybe just develop a good taste, and don’t bother with putting an arbitrary hard-limit on how code should look.
Preach, Erez! Couldn’t agree more
Thanks for writing that.
This problem is especially visible when you boot FreeBSD or Linux on a 80 columns console without any framebuffer addons or other other then ‘plain’ resolution.
No matter if FreeBSD, Linux or just a CLI tool I really respect and admire people that ‘FIT’ in thest 80 columns.
I also always try to fit in 80 columns with my scripts and always to go to newline if I am sure that 80 columns will not be enough.
Regards.
One thing that might be worth pointing out is that “enforced by a tool” not only means less review back-and-forth, it’s also *not personal*. People know it applies to *all* code, and they’re not being singled out by a dev in a bad mood.
Also, apart from nobody having to spend time to explain the same thing again, automated feedback is *much* faster than manual feedback. Even if you didn’t realise you could run the checking tools locally before you submit a PR, you’ll start getting CI reports within a reasonably short time, even if you submitted the PR when everyone is asleep.
I heartily agree, specially on the long identifiers. At my company, 60 character-long ones are not unheard of, and make me gag.
The 80-character limit predates terminals, though. The IBM punch card format of 1928 introduced 80 columns (up from 45).
Hereby I declare myself as an “80-column” purist, and in my case is with Python code, but more like 79. Why? PEP8, of course!
And yes, I am aware of big screens, of code-formatting tools like Black that default to 88, and that it’s a matter of preference, but I do find that 79 characters produces perfectly readable code.
Thanks for sharing!
I make tutorials using R in RStudio. To make things visible in video, I set my monitor to 1280 x 720. That means I keep my code to a mere 60 CPL, including comments. As a result, my code is organized more vertically than horizontally. For pedagogical purposes, it’s great: I have one little thought per line, along with a brief explanation. It’s much more digestible foe my students and for me. It’s like poetry vs prose.