为什么在 IDE 中使用单一空间字体？

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

Using spaces for indentation would be a problem once you got deeper than one level.

I personally find the mono-spaced fonts easier to read in code editors. Of course, I'm almost blind. That might make a difference. I currently run consolas font at 15 point with a dark background with high-contrast letters.

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.

I suspect monospaced fonts were a programmer's preference as a carry-over from the text-based DOS days.

On the other hand, I, myself, have tried Verdana and a couple other recommended proportional fonts, but I couldn't deal with the change. My eye is too well trained for monospace. Languages heavy on symbols, like: C/C++, C#, Perl, etc., look too different for me. The placement of symbols makes the code look completely different.

I think, just like the issue of tab characters, the complicating factor is when something is indented for the purposes of alignment, and someone else has different preferences. Things get misaligned.

By the nature of code rather than regular language, it's nicer to have it lined up correctly. Also, in code editing, sometimes you want to block select, block copy and block paste. In Visual Studio, you can do the block selection by using the ALT key while doing your mouse selection. It might be different in different editors, but I've always found that option in an editor very important in some cases, and it wouldn't work very well, unless you are using a mono-spaced font.

If you work in a team then mono-spaced fonts ensure that code is clear and correctly layed out for everyone, whatever mono-spaced font they prefer to use.

Your code may look clear to you when using a variable width font but it's unlikely to look the same if a mono-spaced font user opens it.

I use Comic Sans MS, which looks quite reasonable as small point sizes (it only starts looking "jokey" at headline sizes). It's easy on the eyes, yet still keep the text small enough to have a reasonable amount of code visible in the text window, with several of VS's docked panels open.

You can have the Solution Explorer panel out, and still have 100 columns of text readable without horizontal scrolling. Moveover, I can have the DXCore Documentor panel (displaying formatted XMLDOCs) open wide enough to read while still being able to see enough of the text to doc the XMLdocs.

Mostly for alignment purposes (such as when function parameter declarations span multiple lines and you want to line them up, or lining up comments, etc.).

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!)

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.

All it takes is a few hours of trying to figure out why a search isn't finding something because you have 2 spaces instead of 1 in your literal, to realize you should use Monospace fonts. I had this happen to me once when trying to fix a Lotus Notes agent, when the designer wasn't using a monospace font. It wasn't until I pasted the code into CodeWright to print it out that it was obvious what the problem was.

Monospaced fonts make it much easier to line up code.

This is especially true when working with a team; everyone in the team can use different fonts, and as long as they're all monospaced, everything will line up. Similarly, if a single person uses many different development tools, everything will line up if they're all monospaced. If they weren't all monospaced, you'd have to make sure that they all use the same font, and if you're developing on two platforms, that can be difficult.

In fact, some development tools only support monospaced fonts.

Another reason is that monospaced fonts tend to have more distinct characters. Compare lIiO0 to lIiO0, and you'll see what I mean. They also make it much easier to count whitespace.

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.