No Buses All Morning

And then two come along at once.

Not literally. I’m referring to the fact that I’ve been posting for nearly three weeks without a response, then yesterday I got two! What pearl of wisdom elicited such a frenzy of responses? Climate change, keyboards, 3D printing? No; it was:

Proportional Coding

Thanks to

Code layout again, by JBanana

Fixed Fonts, by thrig

for taking the time to reply! I will return the courtesy.

Autoformatting

To JBanana first, who mentions Go’s autoformatting and that it’s a reason for not liking Go. I mentioned both Dart and Go in my post, but that was perhaps a mistake—because the two languages are about as different philosophically as it’s possible to be.

I’m not a fan of Go. Nothing against the project—it’s great at what it does. But pretty much every design choice is opposite to what I would have done. And then there’s Dart, which I like very much.

So let me talk about autoformatting, but just in Dart.

I work—have worked for fifteen years—at a company where every line of code gets reviewed by another engineer. Before Dart, I coded in Java.

Part of the miracle of Dart for me was realizing that I was Never. Going. To. Have. Another. Discussion. About. Whitespace. In. A. Code. Review.

That’s mostly a selfish gain, because discussing about whitespace in a code review can be important; but it’s not fun. I was happy.

There’s another selfish gain to autoformatting, which is that it makes code much smoother to write. All the work you used to do to indent nicely—gone. “Format on save” and everything is grand. It’s fantastic.

But the real gain, and this is a callback to the first sentence of my “Proportional Coding” post, is readability. Because what auto formatting gets you is consistency. And what good auto formatting gets you, is very carefully tuned consistency.

Laying out code to make it maximally readable can be an art—but no two programmers will exactly agree, and ten programmers will bring ten variations. If you work in big codebases, you get used to reading lots of different variations on lots of different styles, even when an attempt is made to achieve some kind of consistency during code review.

And so a cleverly tuned algorithm cuts through all that in a very pleasing way. The bigger the codebase, the bigger the benefit. I work in a huge codebase and autoformatting is a killer feature here.

Not all auto formatters are great; sometimes the approach take is “the benefits of autoformatting are so big, it doesn’t matter if it’s a bit ugly”. On balance I tend to agree—but only reluctantly. It’s much better if you can autoformat in a beautiful way. The Dart formatter was designed to match what real people want—not a simplified ideal. As you may have gathered by this point, I like the result.

JBanana also said:

> If I’m reading ordinary text, I start at the left and work across. But if I’m reading code, I never do that. I want to see the structure, and I get more of that with a monospace font.

That certainly makes sense if horizontal alignment is used to add structure or emphasis; indeed, that’s about the only way a fixed width font can add value. But you do give up a lot to get that. There’s plenty of structure at a higher level—class structure, method structure—that is easier to see when viewing with the gentler proportional font.

To some extent, coding alongside an auto formatter forces you to express structure in more concrete ways: in the actual API of your classes, in comments, in how you structure into files and packages. I think this shift in focus is a win, because these all have long term implications for maintenance and use.

IDEs vs Terminals

Thrig seemed mostly worried about games, colours and OpenBSD. All reasonable concerns but not, I admit, ones that were at the top of my mind.

ASCII art based games should used fixed fonts, you got me there.

I do heavily use a terminal with a fixed font; there are too many CLI tools that rely on it for coherent output. I don’t tend to read large amounts of text or edit large amounts of code in the terminal. I did once build a UI that would default to a proportional font but detect “fixed layout” text and switch to a fixed font, but I’m not aware of any terminal that can do this, nor have I looked for one. Anyway! Second point conceded.

To specifically answer the remaining points about needing a non-terminal-based editor to try coding in a proportional font: you could try VSCode. You can

Disable The Colours

Add VIM Emulation

Code Remotely

Sadly it doesn’t appear to run natively on OpenBSD; but it doesn’t run remotely on ChromeOS either, and that hasn’t stopped me from using it. You will need a box somewhere running Linux/MacOS/Windows.

I’m not sure quite what “integrate with the usual four xterms” meant. Probably not?

Conclusion

I wasn’t trolling, honest!

I’ve been coding with a proportional font for the best part of 20 years. I like to mention it from time to time in case people haven’t tried it. Most people don’t like it, but a few who try it will, and then that’s a pretty big win for them.

In general I like encouraging people to question their work habits. Just as with all my other idiosyncrasies; these are just the ones I got around to posting so far:

Why bash or zsh when there’s fish?

Why is your keyboard shaped like a typewriter?

Why sit when you could stand?

There will be more—they’re fun to write and I guess a different opinion to the mainstream is at least mildly interesting to read.

What’s that handy phrase? Ah yes—your mileage may vary.

Feedback 📮

👍 Thanks!

👎 Not for me.

🤷 No opinion.

Comments.

So far today, 2024-05-12, feedback has been received 2 times. Of these, 0 were likely from bots, and 2 might have been from real people. Thank you, maybe-real people!