Is an 80 Character Code Line Length Still Relevant?
If you’ve spent any time reading about coding standards on the internet, you’ve probably come across the suggestion to limit lines of code to 80 characters and wondered if it’s still relevant today. The advise to limit lines to 80 characters is often connected to the historical limit of 80 characters in terminal windows. But what if your team is not subject to this constraint? Are there still any benefits to adopting this limitation? I tried living with it for a while and here are my takeaways.
Growing pains
Indentation
When I first set out to try this style out, the first thing I noticed was that 80 characters is not a whole heck of a lot of space to write in. You can run up against it pretty quickly and you will need to figure out a strategy for how and where to wrap longer lines. I happened to be trying this out as part of the NPM coding style, which also meant 2-space indentation and comma-first wrapping. I was more of a tabs-only guy before, not really caring if it was 2 or 4 spaces, but if you adopt the 80 character line limit, 4-space indents become grossly wasteful of precious characters. You can still do it, but you will feel the squeeze. I highly recommend 2-space indents for a much more comfortable experience.
Line Wrapping
In practice, fitting code into 80 character will eventually require wrapping long lines of code. This is language and style-specific, and the only general rule is to be consistent. Wrapping long lines of code takes a little bit of getting used to, but I’ve never found it to be too cumbersome because there’s rarely a need to re-flow an entire paragraph of code. In contrast, fitting comments into 80 characters can be unexpectedly awkward. I often find myself revising comments to add detail, improve clarity, or just to improve the grammar or wording. This changes line lengths, which often leave the rest of the paragraph’s flow needing changing. Thankfully, there’s an extension for that! I’ve been using Rewrap for VS Code, and there’s a version for Visual Studio, too.
Benefits
Getting enough space to work with on each line and automatically adjusting paragraph flow were the biggest problems that I ran into in adopting this style, and once those were solved, it was pretty smooth sailing. Here’s what I noticed as I started to work in code that was all 80 characters wide.
Naming
Long variable names are more descriptive variable names, but there’s a limit to how long they can get before they start to suffer in readability. The short line lengths started making me think more about building up a vocabulary of consistent abbreviations that made variables shorter and easier to read.
Nesting
When you only have 80 characters and each indent level is taking at least 2, you feel the pressure not to nest too deeply. You know what acts as a kind of reset on indentation levels? Moving code into a new function. I’m already a big believer in using functions not only to encapsulate logic, but also to give descriptive names to what’s encapsulated. The 80 character limit discouraged monolithic, deeply nested functions and encouraged breaking code into smaller, less nested functions.
Viewing
I’m kind of a minimalist when it comes to monitors. I never really bought into the idea that your productivity scales linearly with how much screen space you have. I do think more screen space helps, but there are diminishing returns. The point of that is, I have at most two 1080p monitors that I work on. Sometimes just my laptop monitor. At that resolution, I discovered something really nice about code files 80 characters wide: it became comfortable to have two up side-by-side in a split editor view, with enough room left over for VS or Code’s explorer pane. No horizontal scrolling necessary! To me, this is a killer feature and reason enough to recommend adopting the 80-character width limit in your code base as well.
Conclusion
Looking back, it really wasn’t all that difficult to adopt the 80-character line length limit, and it had benefits far exceeding simple accessibility for people limited to an 80-character-wide terminal. I would recommend giving this coding style a try! I don’t think there is anything especially magical about the number 80; you could probably gain similar benefits from a slightly wider length, but only slightly. I experimented briefly with 100 characters and that definitely felt too wide. Late-breaking realization: I’ve never tried this with HTML, where you don’t have the same tools to reset indentation levels that you have in a programming language. It might be possible to apply this rule to HTML, but I suspect it would be a bit harder.
Have you adopted a maximum line length in your projects? Did you hit any obstacles or discover any benefits that I didn’t mention? Sound off in the comments if so!
