I recently had a discussion with a colleague about whether we should introduce a character count limit per line into our style guide. He believes it enhances readability, while I argue that readability should be facilitated by the editor or IDE, not the content itself. However, I wasn't entirely confident in my stance, as line limits seem to be a common feature in the style guides of many major open-source projects. Surely, there must be a good reason for this that I might have overlooked! So I started researching this niche question.
Turns out I’m not the first one who wondered about this (duh) - but I wasn’t expecting this rabbit hole of heated internet discussions about such an arguably unimportant topic. Quite annoying, that there was no definitive answer - However, there are several reasons why it might make sense in certain cases. Let’s dive in!
Line Limits Today
From now on I will use the term CPL to refer to "characters per line", since we are going to use this term a lot!
Let's first look at some popular open-source projects & coding standards:
| Repository | Programming Language(s) | Line Length Limit | Notes |
| Linux Kernel | C | 80 CPL | They also have 100 CPL for Rust docs |
| Google Style Guides | Various | 80 CPL (CPP) and 100 CPL (Java) with exceptions | Google's style guides for different languages have various line limits (or none at all) |
| Apache Hadoop | Java | 80 CPL | Follows Sun's Java conventions with some modifications. |
| PEP 8 (Python) | Python | 79 CPL for code, 72 CPL for documentation | Recommended by Python Enhancement Proposal 8 for Python code. |
| Django | Python | 88 CPL for code, 79 CPL for documentation | Adheres to Django's style guide, making an exception to PEP 8 in favour of the Black formatter (which uses 88). |
| React | JavaScript, JSX | 80 CPL | Enforced through ESLint for JavaScript/JSX code. |
| WordPress | PHP & JavaScript | usually 80 CPL, not exceeding 100 CPL (soft limit) | Follows the WordPress Coding Standards. |
It's a mess. And, these are just a couple of examples. I saw repositories using no limits, 70, 72, 79, 80, 88, 90, 95, 100, 120, 125, 130, 132 CPL and then some of these are hard limits; some are soft limits; some only apply to code and others to documentation. So clearly everybody has a different opinion on these!
These limits seem to be quite important to people, as they sparked various discussions (just a couple of examples).
Guys, we're not in the 1970's anymore.
... is often the reasoning behind arguing against line limits. So where do they actually come from?
The Origins of Line Limits
It probably all started with typewriters (and teleprinters). They typically had a character limitation of around 70 to 90 CPL due to the letter paper size and the mechanical designs of the typewriter carriage [Source]. But there wasn't really a standardized format.
The 80 CPL convention dates back to the era of punch cards (the early 20th century until the late 1970s), particularly with IBM punch cards used in early computing, which could hold up to 12 rows and 80 columns.
This card was used to load software into a mainframe computer. Each byte (the letter 'A', for example) is entered by punching out a column of holes. Contents appear to be a line from a Fortran program - [Source]
This carried over to the earliest computer terminals such as DECs VT52 and VT100, which displayed 80 CPL across 24 lines [Source]. To this date, many terminal emulators use 80x24 characters as the default resolution.
Do We Still Need Line Limits?
So the whole line limit thing (especially the 80-character limit) started with punch cards. Most other limits are relaxations based on this limit. Why did we relax them? Well, displays got better; we now render terminals/code inside smaller windows and our programming languages got more verbose.
But do we need them at all?
Well, I can see why they kept the punch card CPL limits for the first terminals at least. Since code is left-aligned and most characters are placed on the left portion of the screen, limiting the count of characters per line forces developers to split long lines of text into multiple lines which means no need for horizontal scrolling.
However, nowadays, we don’t have small fixed-size fullscreen terminals anymore. Hell, even if you use your code editor area fullscreen (who does that?!) there are so many different display sizes and resolutions. But I rarely see developers who have their text editor stretch across the whole screen. We use different windows with basically unlimited different window sizes - and if not, your IDE probably has a sidebar or other UI elements, leading to non-standard text-content-view sizes (meaning the area which actually displays text).
Even if you assume that every developer has a similarly sized text editor, we might still use different font sizes (or typefaces).
In discussions, I often heard the reasoning, that those line limits definitely won’t fit all but they are good enough approximations of the average window size - and that bit of empty space does not bother them.
Well, to me it does! Why do we have big monitors and the possibility of adjusting windows to maximize screen real estate, when we cannot use them? I often have multiple files and software (browser, debugger, docs) open in parallel.
I would be totally sold if there was an automated way to adjust those line limits depending on my window size to prevent cut-off text or unused empty space! If there only was a feature like this (foreshadowing).
But having those line limits built-in to the codebase means there is no (trivial) way of doing it automatically since the text is already (vertically) shortened and would have to be reconstructed first.
Another big problem is that these limits force developers to split lines into new ones to avoid horizontal scrolling. This just shifts the problem and results in more vertical scrolling, as the text becomes longer vertically, even if you have a very wide display.
Take this screenshot as an example:
Same TypeScript code - 60 characters per line on the left, 120 on the right. The code with the 60-character line limit is twice as high.
Why should someone writing code decide how I want to read the text and size my window? Shouldn't this be the responsibility of the text editor?
Well, some people argue that it allows them to read faster. Is this true? There is not a lot of ‘real‘ research in this field, but I found an interesting study by Atilgan, et al. (https://www.pnas.org/doi/full/10.1073/pnas.2007514117).
They determined that there is a minimum limit of characters per line at around 13 characters for normal-sighted people when reading text (not code). A maximum does not seem to exist (though this was not the focus of the study). However, the participants did not have to scroll at any point because the text automatically wrapped to the next line near the end of the display area.
Then there is also this Study by Shaik, et al. which was sponsored by Microsoft (https://www.semanticscholar.org/paper/The-effect-of-line-length-and-passage-type-on-and-Shaikh-Chaparro/4539b499d5b9d911901a99460dda3da7ce037041). They also find that longer CPLs lead to faster reading speeds independent of the type of text (narrative passages and news articles). However, they found that the comprehension of texts (not code) could actually be better when using shorter line lengths; the personal preferences of readers might be completely different - tough results are not very conclusive.
Alternatives to Line Limits
So what do I propose instead?
There are two alternatives - one we already touched: Horizontal scrolling. There are a few arguments against this. For one, most people have only one mouse wheel (which is vertically positioned on the mouse) and to scroll horizontally, they need to hold down some other button or use the keyboard. It’s also pretty easy to lose your sense of position in a document when scrolling in two dimensions. The worst part: You might actually overlook some piece of code you were looking for because now it’s easy to ‘scroll’ around something.
So what else is there? Well, what we could do manually by splitting lines (or letting our formatting tool do for us), our editor can do as well - crazy right? It’s called line wrapping. In vscode it can be turned on and off with a simple command or key combination. It will shorten the lines and move content to the next one depending on what fits in your editor window.
Conclusion
I cannot find a single logical reason for why we would actually need character line limits when writing code - at least when we assume that part of the developer’s job is to structure and format their code in a readable way.
But, to be completely honest, sometimes it just feels better to read 80 or 120 CPL limited code. I am not totally sure why, maybe horizontally scrolling is too annoying or the line-wrapping functionality of my editor is bad? Maybe it depends on the programming language or my display? I might have to pay more attention to this gut feeling in future.
Or I just go on, don’t care and use the recommendation of the code style which we are adhering to… Since I spent way too much time researching this and who cares anyway…
Also it probably just makes sense to have any kind of line limit in big projects to prevent trolls from abusing it.
By the way, after some more personal research, I found the perfect solution to make code more readable: Center-alignment.
Just kidding - please don’t.
Cheers