2012-05-24

I code with a catapult

I decided to try something this year. For my entire programming career, I have used a fixed-width font while coding. Of course, when I first started coding, fixed-width fonts were all a computer could do; and even these days, command line interfaces still predominately depend on a fixed-width font for display (especially if they try to draw boxes or other pseudo-graphical elements). Even as I type this blog post using Blogger's HTML editor, the edit window uses fixed-width characters; and if I wrap some text in <code> tags, chances are your browser will also render that text with a fixed-width font (even if Blogger didn't apply a custom style to it). But for a long time now, computers have been able to use proportional-width fonts on screen, and many development tools support picking your own font. Yet, whenever I get the inspiration to try a different typeface in my IDE, I always picked from the list of fixed-width fonts. Visual Studio seems to encourage this by making fixed-width fonts bold in the font dialog.

(Although, admittedly, it is convenient to know which fonts are fixed vs. proportional at a glance, and bolding one or the other is a simple way to show the difference.)

But I had read a handful of blog posts from developers claiming how it is easier to read code when they view it in a proportional-width font. The discussion often includes pros and cons of viewing code in a "literary" font vs. a "computer" font, and often includes a discussion of tabs vs. spaces (the reverse is also true: discussions about tabs vs. spaces often include someone commenting on the benefits of one vs. the other when using a proportional-width font instead of a fixed-width font). I decided that I wanted to try something new, and maybe I'd give this developing-in-a-proportional-width-font thing a try.

The major criterion I've found for picking a font is that it must have very distinct characters. Fonts where a number 1 looks like a capital I looks like a lower case l, where a number 0 looks like a capital O looks like a pair of (), and where (parentheses), [brackets], and {braces} are too similar (or just too "weird"), tend to cause more headaches and annoyances than their otherwise typographical good looks are worth. Also, the font should, obviously, be supported (Visual Studio only supports TrueType fonts in the IDE), and it should be legible (and similar characters distinguishable) at smallish sizes (I tend to view my code at 8 or 9 point). It's also helpful if it's one of the "standard" fonts that is available on nearly every machine (i.e., you don't have to try and find a legal, free download every time you want to use it on a new machine). One proportional-width font that fits these criteria fairly well (no font is perfect on all counts) is Trebuchet MS.

To make a long story short, I'm lovin' it. I've found it much easier on the eyes to read through code. It looks neater, cleaner, more professional, and more tidy (even if the actual code is a mess). And while I realize this "analysis" is all based on subjective, personal preferences, in my opinion a font choice when doing development is exactly that. The proportional font also helps view wider lines on the screen. Now, in an ideal world, you should never let your code lines get so wide that you need to change fonts to read them all, there are times where it is necessary to have a wide line (especially in HTML, where a browser — and I'm not just talking about IE here — behave oddly when you try to insert a line break).

Since commentary on font style is almost never complete without tabs vs. spaces, I'll add my 2¢ here. Personally, I prefer tabs, because they are more compact (one character vs. [number of spaces]), more customizable (most IDEs worth their salt let you specify the size of a "tab stop"), less prone to error (you can type three spaces instead of four, but you can't type half a tab), and easier to navigate (to back up an indent level, you only have to press the left arrow or delete key once, instead of four, six, or eight times). The arguments I've heard for spaces over tabs, I either don't agree with or I don't (personally) think matter: they are uniform across all IDEs (agreed, it is jarring to open a code file in another tool [e.g., a diff tool] and see it display tabs at a very different width), they display the code as written (arrogance; why is the way John Q. Developer aligned the code the "right" or "only" way to view that code?), and they allow for more precise aligning of things like variable declarations (irrelevant; you can tab to the proper indent and use spaces for fine alignment, if necessary). But these are just my opinions, as everyone has their own (and, as a quick scan of the internet shows, some hold to their own opinion with something approaching fanaticism or zealotry that makes it not worth arguing).

I've found that using a proportional-width font seems to work best with tabs, since it helps you keep the code consitently indented no matter which font you use. (Plus, if you prefer larger indents, you end up having to use even more spaces to get the same depth as with a fixed-width font.) However, there is one potential drawback to using a proportional-width font that neither tabs nor spaces can solve, and that's aligning of variable declarations (or other similarly-formatted code blocks). See this picture for an example:

In a proportional-width font, you can't use spaces to align the variable names with the first line. Not only would it vary depending on your choice of font, but there's no guarantee that the sum of the widths of the letters in the variable type is evenly divisible by the width of a space. (You can use tabs to align them with a tab stop, but again, that will depend on the size of your tab stop and whether the variable type name fits within one or two [or more] tab stops.) If that matters enough to you, this may be a deal-breaker; but it's one of the things I've found, in practice, doesn't matter that much when you can just indent the dependent lines like so:

If you haven't tried coding with a proportional-width font, I highly encourage you to give it a try. At best, you might like it. At worst, you can always change it back.

No comments: