Software developers won’t ever run out of subjects to argue and fight about. Some of them can be fundamental to a project — like choice of language or the programming paradigm to begin with. Others seem more of a personal preference at first, but can end up equally fundamental on a bigger scale — like which character to choose for indentation, where to place the curly braces, or how to handle line breaks. Latest when there’s more than one developer collaborating, it’s time to find a common agreement in form of a coding style guide, which might of course require a bit of compromise.
Regardless of taste, the worst decision is having no decision, and even if you don’t agree with a specific detail, it’s usually best to make peace with it for the benefit of uniformly formatted code. In a professional environment, a style guide was ideally worked out collaboratively inside or between teams, and input and opinions of everyone involved were taken into consideration — and if your company doesn’t have one to begin with, the best step to take is probably one towards the exit.
The situation can get a bit more complex in open source projects though, depending on the structure and size of a project. If no official style guide exists, the graceful thing to do is to simply adopt the code base’s current style when contributing to it. But larger projects that are accustomed to a multitude of random contributors will typically have one defined, which was either worked out by the core developers, or declared by its benevolent dictator for life.
In case of the Linux kernel, that’s of course [Linus Torvalds], who has recently shaken up the community with a mailing list response declaring an overly common, often even unwritten rule of code formatting as essentially obsolete: the 80-character line limitation. Considering the notoriety of his rants and crudeness, his response, which was initiated by a line break change in the submitted patch, seems downright diplomatic this time.
[Linus]’ reasoning against a continuing enforcement of 80-char line limits is primarly the fact that screens are simply big enough today to comfortably fit longer lines, even with multiple terminals (or windows) next to each other. As he puts it, the only reason to stick to the limitation is using an actual VT100, which won’t serve much use in kernel development anyway.
Allowing longer lines on the other hand would encourage the use of more verbose variable names and whitespace, which in turn would actually increase readability. Of course, all to a certain extent, and [Linus] obviously doesn’t call for abolishing line breaks altogether. But he has a point; does it really make sense to stick to a decades old, nowadays rather arbitrary-seeming limitation in 2020?
Line Lengths Throughout History
Where does that limitation come from anyway? It seems like one of those things everyone knows about and follows without questioning or really understanding it. The 80 characters are just all around us — there are these devices of yesteryear with their 80 character displays, your terminal emulator’s default width comes preset to 80 columns, and of course all those coding style guides that keep bringing up the 80 character line limit. It all just seems to magically come together somehow, and that’s how things are, period. Well that didn’t help at all now, did it? So let’s take a few steps back.
Yes, since the early days of terminals, the screen size was indeed mostly limited to 80 characters. There were exceptions in either direction, 72 and 132 for example, but 80 was the most common one. Considering we’re talking about the late 1960s here, it seems plausible that display technology simply wasn’t advanced enough to make it feasible to have bigger screens and longer lines, and that’s how they ended up with 80 characters. But that’s not it either.
Sure, the state of 1960s display technology had definitely some impact as well, but the choice was ultimately made out of habit rather than necessity. Back in that time, when the first terminals were designed, people working with anything computer-like primarily knew one common storage media: punched cards. The star of the time, dominating the industry, was IBM’s 80 columns by 12 rows card. And well, that’s pretty much it.
The popularity of that specific card lead to the decision to use the same amount of columns on terminals, which in turn defined it as the golden standard for coding styles, still widely in use today. In a way it’s understandable, considering the 80×12 punched card was quite literally the greatest invention since sliced bread at that time — as both were revealed to the world in July 1928. Yes, the full origin of 80 characters essentially dates back to 1928.
(The card’s patent application was filed July 20th 1928, the first sliced bread was sold July 7th 1928)
Present-day Line Lengths
So here we are, close to a century later, still squeezing text in the same 80 character lines. Well, not everywhere, some languages see it differently today, and if not, frameworks might come with their own guidelines. But while we have larger screens at our disposal nowadays, long lines will eventually interfere with our field of vision. In other words, requires us to move our eyes, or even the entire head, disrupting the reading flow and increasing the risk to overlook something important.
Then again, the discussion isn’t about getting rid of line limits altogether, but challenging an enforced, hard 80 character limits. From a reading comfort point of view, the difference between 80 and 85 for example is negligible, and insisting on the former will at best lead to clumsy line breaks — like the one [Linus] addressed — and worst case to cryptic variable names and other questionable formatting.
A common compromise is to encourage 80 characters, but allow up to 100 or 120 characters, and draw the hard limit there. This way, if you exceed the soft limit, you don’t have to sweat it too much, and by the time you reach the hard limit, there’s enough room to split the lines in a coherent way.
In an ideal world, none of this would matter much, and an IDE would handle all of that transparently for us. We would configure the style guide’s limit, and additionally set our own preferred limit. The IDE presents the code as we prefer it, and saves it the way the style guide asks for it.
While that works quite alright with things like indentation style, line breaks are unfortunately a lot more complex. Where is the right place to split to keep the code readable and preserve logical blocks? If done naively by brute forcing line breaks, we’re exactly back at the point [Linus Torvalds] is trying to make. Maybe machine learning gets us there in the future, but until then, we’re on our own.
What’s Your Limit?
So what’s your take on all this? Where do you have your line length limit set? And do your side projects differ from you work environment here?
Do you agree with [Linus] and say enough already with the forced 80 character madness? Or do you prefer even shorter lines?
Let us know in the comments!
No comments:
Post a Comment