But for the record, OS X now ships with a new default monospace font called Menlo which is quite nice... but it's really just Deja Vu Sans Mono with modified punctuation (most importantly though is the slash through the zero).
With modern languages and IDEs, I don't see any benefit to using monospaced fonts at all. I have been using Calibri for the last few years because it is readable and pleasant to look at, and I never have any problems lining things up provided they actually need to line up.
Regardless of IDE support, code is structure and patterns.
Monospaced fonts make it easier for me to spot that structure and observe those patterns, whether to simplify my scanning of the code, help me spot bugs (e.g., omitted punctuation throws off the shape of a form), or navigate within a file.
I do essentially all of my writing — email, web forms, text editing, console — with monospaced fonts.
Patterns are easier to identify with a non-monotonous font, as research into word-shapes shows. Some of the fonts I use have wider-than-usual spaces, or—and perhaps you've noticed this—punctuation like the em dash that have the correct width. Patterns, right?
What you're saying only applies if your "patterns" consist of forcing everything into the same length. I suspect that you might not know what you're talking about, but only because of your choice of language ("shape of a form", "code is structure and patterns" - what exactly is that supposed to mean, if anything?). It would really help me if your points were more concrete, and you gave some real examples.
> Patterns are easier to identify with a non-monotonous font, as
> research into word-shapes shows.
Link?
I doubt most such research is considering code, so I'd like to see your sources. I totally agree that English text is easier to read when correctly typeset, but reading code and reading English are very different activities, at least for me. English is mainly read through occasionally overlapping sweeps, with a linear tendency. I read code by jumping around within constraints established by my understanding of structure.
From experience, I know where to look for arguments, for loop bindings, for destructuring; I know how to read a with-* macro, a declaration, a comment block. If those conventions are violated, my code reading slows and errors can creep in.
> What you're saying only applies if your "patterns" consist of forcing
> everything into the same length.
No, what I'm saying applies whenever structure can be made visible by aligning tokens to a grid. If that grid is 1em wide, the alignment is easy.
Consider a totally trivial non-indentation example: returning the English-language representation of a mathematical operator using case.
Because the operators are all the same width, I can immediately see the syntax error: a break in the column of double-quotes. If those strings were not all aligned to the same grid, the error would not be obvious, and I'd have to rely on syntax highlighting. Syntax highlighting helps in this case, but not always.
The effect is even more profound when considering common test code: it's usual to walk a table of data and answers, applying the same test to each, and thanks to monospacing you can ensure that multiple values are grouped in both axes.
You can achieve this for whole-token alignment with careful tab settings, but I'm sure as hell not going to edit code in Microsoft Word. You cannot achieve it within tokens without using monospaced fonts.
Have you ever worked at a low enough level, or with a programming language that uses short tokens, such that you're interacting with a collection of functions like
/_2op
*_2op
+_2op
-_2op
=_2op
>_2op
<_2op
? Having those be the same width helps my brain "unpack" the meaningful content from the "annotation" (the fact that they're all two-operand functions).
> I suspect that you might not know what you're talking about, but only because
> of your choice of language ("shape of a form", "code is structure and
> patterns" - what exactly is that supposed to mean, if anything?)
What part of "make it easier for me" rubbed you the wrong way? I was conveying personal opinion.
Most of my code is written in various Lisps, in which the structure of code is directly manipulated. I'm not sure how to explain the importance of pattern and structure if you don't get it… perhaps some examples of patterns might help you:
public static void main(String[] args)
public void foo()
public void bar()
The structural layout, indentation, and use of established patterns in code fulfills the same role that, say, 12-bar blues does: everyone knows how to work within the framework, so nobody wastes their time trying to figure out how to communicate before they can make something happen. My opinion is that variable-width fonts inhibits my ability to spot the patterns and structure in the code, so I'm forced to read it more carefully to extract the same information.
I really tried to use proportional fonts for coding, but the kicker for me was selecting text with the mouse (or trackpad). I find it easier to position the pointer when all the letters are the same width. "i"s and "l"s are especially tricky to select accurately with a proportional font.
I've been using non-monospaced fonts for a long time now. I also have had no issues with things I or others have lined up. "Lining things up" usually amounts to screwing around - like variable names having identical lengths, at the expense of clarity. I actually can't think of any issues that I've had. At all. I have noticed that it's a easier to read, scan, and recognize the code. There is, after all, a reason monospaced fonts are hardly ever used elsewhere - not in technical reference manuals, dictionaries, fiction...
I usually keep my mouth shut about it because a lot of programmers identify with monospaced fonts (especially ugly ones). I suggest others do the same: quietly try it, because after the "this is different, therefore I hate it" feeling passes, you might find you prefer it.
When you press the "next-line" key, it's nice to know where you're going to end up. With a non-monospaced-font, you have to guess or count. With a monospaced font, it is visually obvious.
When I hit "Return", it duplicates the current line's leading whitespace on the next line. That will still work perfectly with a proportional font. When I hit "cursor-down", most text editors that allow proportional fonts know how to put the cursor where it visually belongs.
But that is exactly how my next-line key behaves, my cursor is always exactly where it should be. It's not like your tabs/spaces vary in width from line to line it is just that an uppercase W is wider than a lowercase i.
If you only want to move to the next line if you are at the beginning or the end of the line, I guess it works. For any other navigation, your cursor jumps to a random position. I just tried this, and for any line longer than about 3 characters, "next-line" becomes "random position on the next line". Not useful.
Other problems include lining up similar constructs:
my $foo = Foo->new(
bar => 'baz',
quux => 42,
);
With a non-monospaced font, there may not be an integer number of spaces that would allow you to align things.
Using a proportional font for programming seems like using a railgun to put a square peg through a round hole. Sure, you can do it, but why not just get a round peg?
Scintilla-based editors, GTKsourceview-based editors (I just tried with Scite and Gedit) and Emacs all correctly position the cursor when using the arrow keys and proportional fonts.
As for lining up similar constructs, I mostly code in Python, and the PEP 8 style guidelines explicitly forbid that.
I tried it in Emacs. Your definition of correct does not agree with mine.
If you draw a line parallel to the left-hand edge of your monitor down from the character that the cursor is currently over, it should touch the character that "next-line" will move to. That is not what happens when you use a proportional font in Emacs. (If you are on the 10th character of the line, you will move to the 10th character of the next line.)
What happens makes mathematical sense, but Emacs is a visual editor. Programmed text editing is nice, but sometimes you notice a visual property of the source code, and would like to exploit that instead of some lexical property. Visual editing lets you do this, but proportional fonts destroy this ability.
Anyway, sorry to hear about the Python style guidelines. If I did Python, I would ignore that one. (Haskell is whitespace-sensitive and allows you to align similar constructs. So this is just a Python thing.)
> I tried it in Emacs. Your definition of correct does not agree with mine.
Yes it does. In Emacs, with a proportional font, if I'm on the 10th character of a line and press "up", I do not necessarily move to the 10th character of the previous line. I move to the character visually above the current one.
Sorry it doesn't work for you - we must have differing Emacs setups. I'm using Emacs 23 in GUI mode.
Also, I'm a big fan of Haskell in general, but sometimes when I'm coding I think its whitespace is a bit too significant.
Well, part of it comes down to the fact that the text is read differently, depending on whether it's block letters or code. If you're writing prose, you process most text on a word-by-word basis, if not sentence-by-sentence. For instance, periods have very little spacing around them because there actually doesn't need to be that much more distance between letters at sentence boundaries—periods are not crucial characters, and thus do not have to be marked off from other letters. They are themselves boundary markers.
The situation is different with code. Every character that you type, unless it's within a comment, is very important. It's even quite possible that accidentally putting two spaces after a period might have some semantic effect, and it's certainly possible that having two periods instead of one will have some semantic effect. The programmer absolutely must be able to easily read code on a character-by-character basis, and thus he wants a typeface that treats each letter absolutely equally. It's only slightly distracting if your W is wider than your L, disrupting the natural grid of your text. But in a language where punctuation is just as important as the words themselves, you might just as well be troubled if your periods or commas have a tendency to disappear into the flow of letters.
Not to mention that there is nearly no block text font that has as much of an interest in differentiating I/l/1 and 0/O as programming/monospace fonts do.
Maybe for the same reasons you offered: readability and easy to look at.
Some modern monospaced fonts are rather nice to look at, Consolas for example, and the ability to distinguish between 0O1l easily is an advantage for some fonts without having weird letter spacings.
Don't get me wrong, I love Consolas, but having all of the letters be the same width doesn't make sometthing more readable. When was the last time you saw a book or newspaper in Courier New?
When I started my non-monospaced experiment 2 years ago, I, thought I might have trouble differentiating between 0O1Il, etc. but that has never been a problem in practice.
If you code in a style that uses data literals (lists/arrays and dictionaries/hash tables) to represent how an important part of the code is going to work -- e.g. a table that maps letters or keywords to argument lists used in some corresponding function -- then monospace fonts and block selection go well together. You can tweak one column at a time without upsetting the others if you set it up properly.
(Python's PEP8 is meant to take care of abuses, like lining up all the equal signs in a series of assignments or keyword arguments -- you wouldn't think of those as columns of data in a table, so there's no point in formatting the code that way.)
Also, monospace makes punctuation more prominent. Bjarne Stroustrup's C++ reference book uses a mixed font in its code examples, with monospace punctuation characters and proportional-font identifiers. It's weird but effective. I suppose if your code doesn't do exciting things with punctuation characters, and doesn't embed tables of data, then a proportional font would be just fine.
Lucida Sans Typewriter 12 for everything (on my 1280x1024 screens at work). The 75dpi bitmap font.
I even installed my own Emacs 23 with freetype support at work, but after trying EnvyCodeR and Consolas and Anonymous and what have you, I went back to lucidasanstypewriter.
Deja Vu Sans Mono is highly superior to all the mentioned fonts there. It works perfectly clearly with anti-aliasing. I honestly wonder if the people praising other fonts are just trying to be different. I'm probably being subjective. It would be cool to see some research into the top programming fonts to find which are least tiring to the eyes, most legible when tired or scanning, etc.
Call it stealing if you want, but here is a little tutorial on how to get the non-free Consolas font without buying anything from Microsoft. The font is included in a free to download dmg file from microsoft. http://www.wezm.net/2009/03/install-consolas-mac-osx/
They give it away with all of their Visual * Express suites, and there is even a seperate .exe installer for it, so I don't really think it counts as stealing if you use some other method to get it in an easier form.
Nice article, but somewhat incomplete. He misses many fonts (like Lucida Console, Envy Code R, Anonymous, Redhat's excellent Liberation Mono,Pragmata and a whole lot of others), he doesn't explain the font differences other than noting which he likes more, like serif/sanserif, hinting quality, character set coverage (Greek? Cyrillic?) etc.
Deja Vu * is Bitstream Vera * with Unicode characters. Good if you're not using Emacs and want nice-looking λs in your code. (Emacs has a map from character range -> font, so you can use your own Unicode font along with your favorite ASCII font. But using Deja Vu means you don't have to configure that as much.)
FWIW, I use Deja Vu Sans Mono for coding. It is a nice-looking font, especially when grey on black.
But for the record, OS X now ships with a new default monospace font called Menlo which is quite nice... but it's really just Deja Vu Sans Mono with modified punctuation (most importantly though is the slash through the zero).
View it here: http://www.leancrew.com/all-this/2009/06/snow-leopards-new-m...