By my reckoning, six of the ten have major flaws that make them completely unacceptable for use as a programming font. Courier, Profont, Consolas, and Incosolata all have insufficient distinctions between 'l' (lowercase L) and '1' (one). Droid Sans Mono has an 'O' (uppercase O) that can pass for '0' (zero). Perhaps by virtue of the font size, Proggy has a lowercase L that can pass for a vertical bar at a glimpse. If you look closely, Proggy's lowercase L looks like a one -- this is less of an issue because it is visually distinct from Proggy's one glyph, but I still don't like it.
Personally, Proggy is the only font that I can agree with @ spoondan's complaints about. But I wouldn't use it for other reasons. Too narrow for my liking. However, I have to flat out disagree with his assessment of ProFont and Droid Sans Mono having confusing O and 0's. The slash through the middle really drives the point that it's a 0..
Thanks for taking the time to put that together. Please note, however, that I complained about Profont's lowercase L looking like a one, not about its zero. Also, the original article's rendering of Droid Sans Mono does not have a slashed zero. Is the original article in error or did you perhaps accidentally reuse Profont for the Droid Sans Mono sample?
It's possible that you just have sharper eyes than I do; I have been getting older (a deadly habit I keep meaning to break, but the withdrawals seem prohibitive). However, just to clarify, my point is not that these glyphs are indistinguishable when directly compared, but that they can mislead you while reading code. I can certainly tell them apart when I compare them. But can I immediately see that "e1" is "e-one", or that "42l" is the long integer 42? If not, having wasted hours on such stupid things, I would disqualify the font.
1. Working with inherited code, one of the original programmers had an identifier I believed was "el" (short for "element") but that was actually "e1" (presumably short for "element 1"). You don't know frustration until your compiler tells you "undefined identifier 'el'" when, by all appearances, there's nothing wrong with your code. Not only did I waste a couple of hours on this, but the stress probably shortened my life by a few hours, too.
2. Embarrassingly enough: For reasons that I don't understand, I have on a couple of occasions typed a zero where I meant to type an uppercase 'O'. I shipped Python code that had a bug in it because I assigned a value to "box0ffset" instead of "boxOffset". The bug was thankfully minor, and I obviously must have been smoking crack to make this typo, but it has happened and could have been avoided if I'd been using a good font.
3. I've seen C code (I think in an open source project) where the programmer typed something along the lines of "100l". He probably meant to type "100L" and just missed the SHIFT key. By this time, I'd switched to a font that had an "l" that was clearly distinct from a "1", but I imagine that I would have otherwise been utterly perplexed.
These are probably not everyday examples. The circumstances in which confusion is possible are rare. But they do happen and are (in some sense) expensive. At the very least, it's a whole class of errors that's easily and cheaply avoided by choosing an attractive font that minimizes the opportunities for confusion. Why risk the frustration?
I always thought it was amusing that the 3 is right above the 3, and the 0 above the o. I've made a few "leet-speak" errors in the past just due to finger-slips.
Typos like these are some of the hardest to debug. More than once I've been at the point of pulling my hair out on some nonsensical error message that is fixed by simply retyping the line. Trust me, you don't want to waste your time on this one.
