Programming Deserves Better than Monospace
There are many aspects about the ways I use programming tools which are simply not the norm among programmers. The norm I wanted to talk about today is the use of monospace fonts for code, where I instead use proportional fonts.
It is well understood that proportional text is easier to read than monospace text. That’s why just about every piece of text that you will read is proportional. Proportional text, as a technological feat, is more difficult than monospace. That it’s ubiquitous almost everywhere shows how better suited it is as a way to display text meant for humans to read.
Computer source code is almost universally displayed using monospace fonts. My belief is that this is the case not becuase of legibility or practicality, but instead out of tradition and a misplaced belief that monospace text is clearer.
One particular area which monospace is said to excel is in allowing long variable or function names to be legible. My take is that the presence of overly long names in code generally signifies that a codebase has gotten too big and complicated to be easily maintained. If one’s code has reached a point where long names become necessary, it’s probably for the best if the programmer instead refactored or rewrote the code to put all common functionality into one place, simplifying it as a result. Why, then, do programmers prioritize tooling that allows them to cope with longer names? To me, the answer is simply that the priorities are misplaced.
It is a universal practice to use indentation to note which parts of code are inside a larger decision structure like a branch or a loop. Typically, a programmer inputs an indentation by use of the Tab key on their keyboard, which in a code editor may or may not insert a tab. Unfortunately, this practice sometimes extends to using tabs to align certain text horizontally over multiple lines. The legibility gains from this are quite minor, and the consequence is that any other person seeking to read this code is then required to use the same tabulation settings in order to preserve this alignment, not to mention needing to also use monospace text.
I’ve given this problem a lot of thought, and my conclusion is that if code requires a highly specialized tool in order to be read or written properly, then the code is subpar at best. The biggest contributor to this attitude change has been that I’ve started to write computer code exclusively using proportional fonts wherever possible.
If code isn’t formatted according to strict rules, proportional fonts will completely break the layout of the code. The rules for good code under proportional are:
- Only use tab characters to indent the start of lines, as spaces are too small.
- Do not use more than one consecutive space character between names or symbols.
Simple. Effective. Most code does not follow this rule, using white space to align text in ways that simply do not function with proportional text.
Now, one particular grievance one may have against this method of laying out text in a program is the famous “Tabs vs. Spaces” debate. The advantage of using spaces for indentation is simply that it is allegedly consistent for everyone, while the advantage to tabs is configurability.
Proportional fonts solve this debate by having space characters be much too narrow to be useful in any way, effectively forcing the use of tab characters. It’s a form of opinionism, where one’s software choices will inherently make certain courses of action easier than others. Strongly opinionate software frees the user from needing to make choices that are irrelevant. An additional gain is that the customary 8-character size of a tab is usually regarded as too big in monospace — but in proportional, that idea is completely incoherent. Most programs appear to measure proportional tab stops at distances of either four zero-digits (the visual width of 0000) or eight spaces, which are usually comparable. Overly-wide tabs have never been a problem for me in proportional.
Another advantage to proportional fonts is line length. Because fixed-width text is, well, fixed, most characters in monospace are much wider than in proportional. This has consequences in programming because long lines become unreadable, leading to frequent guidance that lines of code be no longer than 72–120 characters. If a line is too long, usually one must enter a hard line break at a logical point, and use spaces to align the broken parts where they would make sense. As I’ve already discussed, proportional fonts make the use of spaces to align text rather difficult, but I’ve found that when programming in proportional, I never need to break long lines. Long lines either don’t wrap (because they are visually much shorter) or, when they are too long, the line will just wrap to the next in a way that’s easy to understand. Most code editors fail at this because they operate as if they were still on typewriters (or on displays meant to emulate typewriters). Another idea rendered incoherent by rendering text in a much legible manner.
The point I want to drive home is this: There are entire classes of inane programming problems that arise out of the regressive preference for monospace, and switching to proportional entirely eliminates those problems. I’ve programmed on proportional for over a year at this point, and I will never look back. You should consider switching, too.
Programmers should strive for technology that is more usable and less prone to weird problems than a typewriter.