What about line length, anyway?

Jan 29 2022

Within the course of a working day, I’ve had to deal with: a conditional statement which scrolled off the right side of my screen (on a large monitor with the IDE maxed), a 1000+ character executable line, and git diffs which required using scrolling the diff widget to determine what changed. It feels like it’s harder than it should be. These lines seem longer than they should be.

Line length controversy

All linters and formatters have line length rules. All of them. Every single one of them which I am aware of. In my experience, programmers preferring long lines rarely employ linters or formatters for any reason.

From reading online, the following opinions are prevalent, with people who:

believe long lines are a feature to be exploited with wide monitors and terminals.
believe long lines grossly inhibit readability regardless of monitor or terminal width.
explicitly state they have no opinion either way (a very small set).
understand the conversation needs to be about readability and clarity of intent, where line length and related measures of class and method length stand in as proxies.

I am in the “Shorter lines are generally better” camp. The benefit of shorter lines is encouraging an economy of expression, in a less-is-more style. This requires extra thought. Long lines may point at opportunities for design improvements. I’ve worked in a code base where if conditions might require three or four hundred columns, scrolling off-screen even on my biggest monitor with the editor window maximized.

Interestingly enough, I have read very few complaints about lines being too short.

How to approach remediation

The first thing to consider when considering line lengths, more specifically, line length constraints, is whether it’s a conversation worth having. People who are comfortable with, or even prefer long lines in the source code are unlikely to be swayed by research findings contradicting their experience or preference. If there is even passive resistance to constraining line length, consider punting any discussion to a later date. If the line length conversation is part of a general code quality and readability project, consider getting some easier quality wins established first.

The difficulty with enforcing or remediating excessively long lines is it immediately requires the programmer to rethink their approach. Programmers used to writing long or very long lines may find this burdensome to the extent of dropping them out of a flow state. These programmers are likely to resist constraining line lengths.

In some teams, the line length standard may be set by the technical leads is using a single development window on a very large monitor, with the IDE maximized on the screen. There may be lines which are hundreds of columns in length.

My take on it is the following:

With contention around line lengths, think very hard about whether it’s a battle worth fighting. Those adamantly opposed to line length constraints are unlikely to be swayed by readability arguments. Make your own lines short and eminently readable. Demonstrate your belief.

When the will exists to constrain line lengths, be overly generous and focus on readability. This may result in some lines being much longer than optimal. These can be shortened later.

Both of these will make advocates of shorter lines unhappy, but without dictatorial enforcement, most people are going to do the most convenient thing at the moment. If a super long line is most convenient, attempting to fight that is fighting human nature.

Making lines shorter

Constraining line lengths could be considered a forcing function for increasing the readability of code, and possibly indicating areas benefiting from better code design. Here are a few ways to do it:

Heredocs allow formatting into a nice, easily readable blocks of text.
Well-named predicates refactor complex conditionals into easily tested, easily readable methods.
Chained calls can be reformatted to align on the dots. This is especially useful with complex, chained AREL calls in Rails.
Embedded SQL can also be formatted using Heredoc.
Deeply nested conditionals can be refactored into their own methods. A great example of this is GildedRose refactoring kata.
Stack and indent function or method arguments. This applies to both definition and calling.

Some text editors, VS Code for example, allow setting an arbitrary wrap on long lines. This is useful for very specific cases where linebreaks are problematic, such as Markdown going to device display.

As usual, the point isn’t making lines as short as possible. The point is being intentional about the code, and considerate of readers (which may include you as the author at some later time).

Links & Commentary

Readability: The Optimal Line Length is an article written for the UX community rather than programmers. Summarizing: long lines lose sales. A case might be made that results on line length acquired from ECommerce results do not apply to programming. Programmers are not customers, and are paid to read lines regardless of length.
If you’re Dan Luu you can do whatever you want. The value of Dan’s content (to me) is worth struggling with long lines. Typically I read his content in a dedicated browser window which I make very narrow.
Line lengths from Hacker News A main point of conversation is that “code isn’t like natural language” hence line length results for natural language do not apply. There are some very strong opinions in this discussion, some of which spill over into opposition to standardized formatting. I find the “code is special” argument tedious. I work hard to ensure my code is readable in a natural language sort of way. I don’t even like the word “code.” Another person suggests that when code is hard to read it indicates a lack of familiarity with the programming language, an assertion which is laughably naive, even egocentric if applied at the team level. I once worked with someone who stated “the code was hard to write, it should be hard to read.” This person was also of the stated opinion that it was not his problem if the reviewer had trouble with his code. He also refused to lint, and in fact managed to get an ongoing linting project halted.
More from Hacker News discussing a post on the Linux kernel list where Linus weighs in.
Coding Horror provides an article I’ve read multiple times, including the comments, and still cannot recall if the author reached a definite conclusion regarding line length. Read it for yourself, draw your own conclusions.
Break Long Lines at C2 wiki points out that making lines shorter may increase method or function length unacceptably. Then notes that the increase may also point to more fundamental design issues.
From python black docs

"If you’re paid by the lines of code you write, you can pass --line-length with a lower number. Black will try to respect that. However, sometimes it won’t be able to without breaking other rules. In those rare cases, auto-formatted code will exceed your allotted limit.

You can also increase it, but remember that people with sight disabilities find it harder to work with line lengths exceeding 100 characters. It also adversely affects side-by-side diff review on typical screen resolutions. Long lines also make it harder to present code neatly in documentation or talk slides."

There is at least one valid use case for long lines: rendered markdown displayed on mobile devices.