Why use monospace fonts in your IDE? [closed]

I've seen a couple of font topics on SO and it seems a majority of people use monospace fonts for programming tasks. I have been using Verdana for programming for a couple of years and I really like the enhanced readability, without missing anything monospace related.

Why do you use a monospace font?

Solution 1:

In a monospace font:

Equal-length string literals look equal.
It's easier to see thin punctuation marks like : () {}
Similar characters look more different: Il 0O vs Il 0O
You know whether or not a line will wrap on a window X characters wide. This means that your team can standardize on say 100 character lines and a line will always look like a line

Solution 2:

I've never even considered coding in a proportional font before. So in the interests of science I just switched my editor over to give it a go.

Here are a few observations after fixing a couple of easy tickets:

Code seems extremely dense. Most of my code is around 80 columns, rarely over 100. A proportional fonts squishes it down to a tiny strip on the left hand side of my editor. Maybe useful if you're short screen space, but it seems unnecessarily compact.
The 'texture' of the code is lost. It's hard to tell what kind of structure I'm looking at - it's just a big slab of text that needs to be read almost character-by-character.
It's very easy to miss the ! operator in if (!foo). (if (!foo), see!)
Punctuation characters are very badly defined. Many are hard to tell apart ({}[]() vs {}[]())
Some punctuation characters are much larger than others, inferring emphasis where none is intended ($@% vs $@%)
Some characters are very narrow, and very hard to identify ('"!;:,. vs '"!;:,.)
Some numbers and letters are very similar (0Oo iIl vs 0Oo iIl)
I am extremely reliant on syntax highlighting, without it it's nearly impossible to do things like confirm quotes are balanced, etc.
Alignment (apart from simple indenting) is completely broken. You can sort of wing it by throwing in extra spaces, but because of the proportional nature of the fonts, the lines may not line up exactly - code looks messier.
Regular expressions are.. interesting!

There are some positive points, though. Admittedly I've only been using it for a little while, but there are certainly some aspects that work a little better with proportional fonts:

'words' are easier to read - spelling errors (eg spelling a variable incorrectly) jump out at you.
I feel better about using longer, more descriptive variable names (maybe because they scan better, maybe because the horizontal size of the text is compressed)
It seems slightly easier to read code like this. It's easier for my brain to 'tokenise' each word and understand its meaning. Although because the punctuation characters are harder to read it's still hard going - but maybe that will change given a bit of time to get used to it

I'll update this answer again tomorrow (assuming I can make it through an entire day like this!)

Solution 3:

I like to line up related conditionals, to try to make it more obvious that they are grouped. For example:

if ((var1 == FOO) && ((var2 == BAR) ||
                      (var2 == FOOBAR)))

Variable width fonts make this more difficult.

Solution 4:

One thing I keep seeing in here is discussion of "lining up code" and indentation. I would like to point the following things out:

eight spaces will always be twice as long as four spaces in any font.
two tabs will always be twice as long as one tab in any font.
any identifier on one line will always be the same width on the next line...in any font!
sure, if your teammates are using monospace and you're not, it'll look different...but you should be standardizing on something--whatever it is--and if that's true then it'll look the same for everyone...in ANY font! For laughs you could also try keeping everyone on monospace and giving half of them widescreen monitors...see how that goes.
If you're doing anything that relies on lining up code based on the columnar position of those characters on the screen, and not the scope of the identifiers you're using, I pose that what you're doing is a hack. Identifiers should never be constrained to a certain number of characters at the cost of the quality of their names. Aside from that...you're not still drawing ASCII boxes with asterisks for comments in your code, are you?

So drawing all of this together, if you start each line at the same place, and consistent spacing is the same width, and the identifiers don't spontaneously change width on each line, then your code actually WILL line up! ...until something is different.

for example:

identifier.Method().Property.ToString();
identifier.Method().OtherGuy.ToString(); //how lined up and pretty!
identifier.Method().Sumthing.YouGetThePoint;

identifier.Method().Property.ToString();
identifier.Method().OtherGuy.ToString(); //oh no! misaligned!
identifier.Method().Sumthing.YouGetThePoint; //...but who cares? they're different properties!

The one point I'll concede is that non-alphanumeric characters are typically not very wide; these include )(][}{,:|";',`! and . This however could be fixed in a font editor...simply by making them wider. It's not a problem inherent with non-monospace; there just hasn't been a lot of demand for it, and so it hasn't been done yet.

In summary, personal preference is fine, but I think there's little practical reason to prefer monospace over non-monospace. You like the look of it? Sure, do monospace. You want more stuff to fit on your screen? Go non-mono. But the way people treat non-monospace like heresy is a little overblown.

Solution 5:

I've become curious by this thread because many arguments for monospaced fonts can really be rebutted easily with some tweaking. So I switched my IDE to Calibri (because it has a nice, round face and is optimized for readability on screens for UI – perfect). Now I obviously have to use tabs instead spaces for indentation (ignoring all the problems) and 4 spaces width is clearly not enough so I switched to 10.

Looks quite good now. However, there are a few obvious problems that I could spot. More might surface later, after I've tested this settings for a while.

As already mentioned, some characters (especially parenthesises, semi-colons) look much too thin. I want this in a continuous text but not in a source code. I think this will be the biggest problem.
Symbols don't align well. As an example, consider the following C# code:
```
var expr = x => x + 1;
```
The arrow (=>) looks like a unit in about any monospace font. It looks like two adjacent characters in other fonts. The same is true for operators like >> etc.
Spaces look tiny. I space my source codes vigorously to enhance readability. This comes to naught when switching to a proportional font. If I could control the width of spaces this would definitely help.
Context-sensitive indentation is completely broken: in some contexts it's not enough to indentate a fixed number of tabs. Take LINQ expressions which might be indented in the following way:
```
var r = from c in "This, apparently, is a test!"
        where !char.IsPunctuation(c)
        select char.ToUpper(c);
```
You simply can't do this with a proportional font.

All in all, characters are too narrow. Again, an additional letter-spacing might help and it's definitely necessary in the case of punctiuation. However, I've got the feeling that all this tweaking to make proportional fonts more readable would just emulate what monospaced fonts to naturally. It's certainly true for all the points mentioned so far.