89

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?

Rik
  • 28,507
  • 14
  • 48
  • 67
  • 5
    Anyone got any good reasons to not use script fonts? :) – jammus Oct 20 '08 at 14:33
  • 1
    Personally, I like to use San Francisco (http://lowendmac.com/backnforth/2k0601.html) for mine ... :) – John Rudy Oct 20 '08 at 14:36
  • I think Trim goes even further than Verdana in making code readable. (http://code.google.com/p/i3project/wiki/Fonts) – user287424 Sep 22 '11 at 00:46
  • At least I'm not the only heretic who uses Verdana. :) – Calmarius Oct 08 '11 at 09:09
  • 18
    Reopen this. Knowing the right tool/technique for a job and the reasons for it is definitely worth discussing. – Thomas Eding Sep 25 '13 at 16:08
  • I am the only one who uses Comic Sans for programming. :) – You Nov 27 '16 at 18:25
  • [Closed so can't answer but here's the one good reason I can think of. When defining formatting guidelines, a font agnostic metric for max line length such as an 80 column ruler is not possible with variable width fonts unless the font to be used is also dictated in the guidelines. Wherever this doesn't matter proportional fonts seem equally good.](https://softwareengineering.stackexchange.com/questions/5473/does-anyone-prefer-proportional-fonts#comment931770_5473) – trss Mar 03 '21 at 18:29
  • Though I liked Verdana, I ended up using the system default font which is San Francisco on macOS Catalina. I thought it's because I like it better. I realised the simple reason is, that's the font I'm used to and hence comfortable with. Even if it's a worse font! :) So system default font is what I'd always prefer is my current thinking. – trss Oct 26 '21 at 14:30

15 Answers15

111

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

Dan
  • 61,568
  • 9
  • 61
  • 78
  • 7
    Nice job! I wonder what font you used, though, since most points you have about certain characters looking too much alike don't bother me at all. – Rik Oct 20 '08 at 19:43
  • 1
    I started with Arial, moved onto Calibri. I tried a few others, but those too seemed to be the best based on 20 seconds of extremely unscientific groping through my font list, and a recommendation from Konrad Rudolph. – Dan Oct 20 '08 at 21:37
  • 6
    "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." How many years have you been programming and gotten used to fixed-width? You have a decent answer here, but you don't account for your own bias (and it would be hard to do that without a lot more work), which isn't very good science. –  Jul 13 '10 at 02:04
  • 2
    @Roger: It may not be good science (doing such a study would be nearly impossible, and very expensive!) but the reasons are plausible. And the broken indentation is a hard-to-beat argument (in current IDEs/editors; this problem is solvable by indenting smartly using tab stops that match the semantics). – Konrad Rudolph Jul 13 '10 at 16:31
  • @Konrad: Don't take my previous comment as too negative (I see now you can read my comment that way; it's hard to convey tone here), your impressions in this answer are useful. It just seemed disingenuous: for example, taking the first observation, of course code seems dense when you have X *years* of using fixed-width and Y *minutes* of using proportional. –  Jul 13 '10 at 19:12
  • As per indentation, that's not a problem. Aligning [multiple](http://stackoverflow.com/questions/3099753/why-do-we-use-fixed-width-fonts-in-our-ides/3100026#3100026) [lines](http://stackoverflow.com/questions/218623/why-use-monospace-fonts-in-your-ide/218646#218646) is a hard-to-beat argument using current tools, but it's used less than normal indentation. –  Jul 13 '10 at 19:15
  • 6
    A proportional font designed specifically for programming would solve most of the usual objections. There are some proportional fonts for coding at http://code.google.com/p/i3project/wiki/Fonts – user287424 Sep 22 '11 at 00:41
  • Which font did you use? – Eamon Nerbonne Jul 16 '14 at 11:54
  • words and spelling should not be an issue since one would be using i18n tools for text symbol manipulation anyway... but I guess it does help? – Marius Mar 23 '15 at 17:03
  • It's funny to me that I can't see your examples because I use a monospace font in my browser for everything. (I hate proportional fonts most of the time.) – SO_fix_the_vote_sorting_bug Dec 13 '22 at 21:46
  • @Roger, Literally the _first line_ is accounting for the bias. And the science part is _making observations_ which is the first step in _any_ scientific endeavor. This is, _by definition,_ science. Please tell me you aren't a science teacher... – SO_fix_the_vote_sorting_bug Dec 13 '22 at 21:48
109

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
Ryan
  • 9,918
  • 7
  • 42
  • 57
  • 35
    The second and third points are really not that specific to monospaced. This is more a question of which particulr font you use, not whether or not it's monospaced. Verdana does well on both points (better than most monospaced fonts, imo), which is why I use it – Rik Oct 20 '08 at 14:36
  • 9
    To correct each of these: Equivalent strings look equal width, and I question why you care about strings that are different and share only a length. Non-monowidth doesn't dictate that punctuation characters are thin; you should use a different non-mono font. "Similar" characters don't necessarily look different in monospace; SimHei for example has identical O vs 0. It's a property of the font, not the width. Finally, if your team actually does standardize, then you can pick non-mono and standardize on "don't let it flow off the screen." – bwerks Aug 22 '10 at 18:31
  • @Rik, I cannot tell the difference between `|` and `l` in Verdana. I agree that readability is important, so I just tested Verdana... It failed being readable to my eyes. My question is: if Verdana does well compared only to _most_ monospaced fonts (which is false by direct observation as many monospaced fonts are designed for programming use) then why not simply choose a monospaced font that gets it right? Answer: because it's _purely subjective_ beyond lookalike characters. Some can admit this fact, others cannot... – SO_fix_the_vote_sorting_bug Dec 13 '22 at 22:21
30

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.

DGentry
  • 16,111
  • 8
  • 50
  • 66
  • 2
    Valid point. But vertically lining up things has a problem: what if you need to change something in that if statement? You will probably need to realign all the stuff. – Calmarius Oct 08 '11 at 09:12
  • 11
    @Calmarius: "making it readable" is part of my all day coding, I do it unconsciously. If you put effort into changing code, you should also put effort in reducing maintenance cost. – Sebastian Mach Feb 27 '12 at 12:38
  • 2
    A better way to achieve this is [elastic tabstops](http://programmers.stackexchange.com/questions/137290), even if you stick with the monospaced font. Not that it's a practical alternative in _current_ editors... – Roman Starkov Feb 28 '12 at 16:30
  • @romkyns: elastic tab stops are smart enough to align the parenthesis with the other parenthesis? – endolith Feb 08 '13 at 15:46
  • 1
    @endolith Well they sure are smarter than *spaces*... :) You still need to decide what you want aligned with what; the big advantage is that once you've done that, things stay aligned even if other things change. – Roman Starkov Feb 08 '13 at 18:23
  • @romkyns: How would you line up the parentheses in this case? – endolith Feb 08 '13 at 18:38
  • 2
    @endolith You would insert a tab between the two parentheses on the first line, and a tab before the opening parenthesis on the second line. Now this would add some extra space between the two parentheses on line 1 in a vanilla implementation, but you'd get an alignment that is maintained on edits, which sounds like a very worthwhile tradeoff to me. In fact, I think I'd even add a tabstop after the closing parenthesis on both lines. See [screenshot](http://i.imgur.com/JdFtiI1.png), in all its variable width font glory, or [try it yourself](http://nickgravgaard.com/elastictabstops/). – Roman Starkov Feb 09 '13 at 20:06
24

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.

bwerks
  • 8,651
  • 14
  • 68
  • 100
  • 3
    +1 for more stuff on your screen. And ASCII boxes... ...well, are waste of time. – Calmarius Oct 08 '11 at 09:33
  • 2
    +1; these points are actually hard to appreciate until one has used a proportional font for a while. – Roman Starkov Feb 28 '12 at 16:39
  • 10
    +1 for the broad-minded realisation that proportional fonts designed specifically for programming can be made and needn’t be monospace. If proportional fonts were more commonplace in programming, a new culture of “programming typography” can emerge. Not so with the “heresy” mindset. – Timwi Feb 28 '12 at 16:55
  • I actually took a stab at making this proportional programmer font--it's not too bad! Font editing is a pain, but you only have to do it once. – bwerks Mar 02 '12 at 17:55
  • 1
    I wish I could up-vote this twice...have been banging these same points over the heads of fellow programmers for years without success. – Paul Gordon Jan 10 '14 at 15:33
  • 3
    You make sweeping assumptions in your points: 1) alignment only needs to happen at the beginning of a line, 2) alignment of similar calls on multiple lines will always be on the same "identifier.Method()" object, 3) columnar position has anything to do with identifier names, 4) the only time one would ever need alignment in comments is for "ASCII boxes with asterisks". Sorry, -1. – Droj Feb 10 '14 at 14:55
  • 3
    I take offense not because you downvoted me, but because you don't offer a shred of counterargument. You basically just recited my points back to me, hah. But yes, I agree! Alignment DOES only matter until lines differ; alignment of method calls with different arguments DON'T matter, because you shouldn't be constraining the length of your variable names; columnar position INDEED DOES NOT have anything to do with identifier names; and the only time you need alignment IS when you're indulging in ascii art on the company dime. – bwerks Feb 10 '14 at 17:45
  • 1
    You are in an empty room with a computer. There is a coding standard that says one method call per line, fluent interfaces need to align on the dot. There is no exit to the north. Go. – MrDosu Mar 04 '15 at 16:34
  • What's wrong with aligning things in columns, such as enum definitions? And [what the heck is wrong with ASCII art](https://github.com/vn-tools/arc_unpacker/blob/master/tests/res/image_test.cc)? – rr- Jan 28 '16 at 14:17
  • @Calmarius, how are boxes a waste of time if the editor creates them in less than the time it takes to get to the next frame of your video card? Like most things in programming editors, it's purely a personal preference. Just be honest and say so instead of pretending it's objective. – SO_fix_the_vote_sorting_bug Dec 13 '22 at 22:00
  • @SO_fix_the_vote_sorting_bug That comment is clearly about wasting time drawing and maintaining ASCII boxes of asterisks around your documentation comments in code. Which editor does that by default? The ones I use doesn't do it. Also it was 11 years ago, it's a bit like calling someone out for saying something in kindergarten... Perhaps these magic editors drawing ascii boxes didn't exist then. – Calmarius Dec 15 '22 at 07:24
16

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.

Konrad Rudolph
  • 530,221
  • 131
  • 937
  • 1,214
  • 1
    Actually Calibri is a bit better than Arial (which is what I was testing with), although it does still exhibit similar problems – Dan Oct 20 '08 at 15:10
  • 1
    I've tried several fonts. Calibri and Lucida Sans Unicode seem to be the most likely candidates. It's no coincidence that Lucida Sans Unicode (under the alias “Lucida Grande”) is OS X's UI font. – Konrad Rudolph Oct 20 '08 at 15:15
  • 1
    Yeah those two are very similar, actually. Calibri wins for me, as it has slightly clearer punctuation. – Dan Oct 20 '08 at 15:25
  • It might just be me, but I've found Calibri's spacing to be incredibly unpredictable--some spaces seem non-existant while others seem huge. Even without regard to programming, I've disabled it on every machine I use. – bwerks Jul 30 '10 at 22:24
  • @bwerks: what do you mean – you “disable” it? Just don’t use it if you don’t like it. Furthermore, when, except in programming, do you use spacing? For formatting? *Don’t*, that’s a mortal sin. Furthermore, what you observe may just be the effect of Microsoft Word’s bad line-breaking algorithm – since Calibri’s spacing is always the same: a space has the same width, always. In particular, it’s not affected by kerning. – Konrad Rudolph Aug 01 '10 at 18:52
  • Segoe UI seems to have a wide enough space character out-of-the-box, though someone I know has simply edited his favourite font to make the space wider. Didn't know one can do that easily. – Roman Starkov Feb 28 '12 at 16:36
  • @romkyns [Fontforge](http://en.wikipedia.org/wiki/Fontforge) is very powerful and apparently quite easy to use (never used it myself). I actually think that Comic Sans is the most readable code font (and I’ve heard there are readability studies that show that Comic Sans is indeed the best font simply in terms of readability). Alas, it’s also butt-ugly. *If* somebody ever designed a nicer-looking alternative (and if code editors supported proportional fonts), this would make me much more inclined towards proportional programming fonts. – Konrad Rudolph Feb 28 '12 at 16:52
  • @KonradRudolph Fontforge is the only free software I know to edit a font, but unfortunately it crashes all the time on Windows 7. I am not sure if it can be fixed, apparently this program was compiled for WinXP or even Win98. – Mikhail V Jul 09 '16 at 21:03
  • @KonradRudolph oops, take my words back, they have released a new version recently, installed it now and it does not crash at least till now. I'm intrigued – Mikhail V Jul 09 '16 at 22:34
12

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.

James Curran
  • 101,701
  • 37
  • 181
  • 258
  • 4
    Oh dude. Why? I'd love to hear your justification for that! – Dan Oct 20 '08 at 14:45
  • 4
    Using comic sans for, well, *anything* :) – Dan Oct 20 '08 at 15:54
  • 1
    My justification is, well, the rest of the message. – James Curran Oct 20 '08 at 18:51
  • 4
    Your justification is "it's small"? Of all the features of Comic Sans, its "smallness" is rarely one gets it chosen often over other fonts. Plus, it makes you look like you're 12. If I worked with you, I would have definitely laughed at you for that by now :) – Dan Oct 20 '08 at 21:46
  • 4
    @Dan, no, it's *readable* WHEN it's small, which IS a frequent priority when choosing a font. And laughing at a person over their font selection makes you look 12. – James Curran Oct 21 '08 at 15:51
  • 5
    Wholly Mackerel - I just tried this and it works. James has probably discovered the only remaining reason for the existence of Comic Sans - it's clearly readable down to 7pt. Next time I have to refactor someone elses' code mess with thousand line methods, this is the font I'll use. – Bevan Nov 10 '08 at 00:42
  • 7
    It very well might be readable, but I still wouldn't go around admitting it in public :) – patricksweeney Feb 06 '09 at 05:10
  • 1
    Now THAT was a shocking experience! I am still not sure about using prop fonts, but Comic Sans IS really usable. I know it's a stupid and abused font that causes random visual terror and should have never come to existence. But it works at small scale and one can consider using it. The rest is just snobism. Thanks, James! – Dercsár Feb 25 '10 at 16:37
  • I use MS Sans Serif (another non-monospace) and even though it only goes down to 9pt, it fits the same amount of lines on the screen, at 57 lines for each font, despite having taller characters--less intra-line space. I have to admit though, I never would have given it the time of day but it didn't look bad at all. – bwerks Jul 30 '10 at 22:29
  • upvoted just because you use comic sans. that's going against the flow for sure – sheldonhull Jul 12 '16 at 15:03
  • https://dtinth.github.io/comic-mono-font/ – SO_fix_the_vote_sorting_bug Dec 13 '22 at 22:02
10

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.

endolith
  • 25,479
  • 34
  • 128
  • 192
SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
10

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.

Tom Robinson
  • 8,348
  • 9
  • 58
  • 102
10

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.

bruceatk
  • 5,118
  • 2
  • 26
  • 36
8

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.

stephenbayer
  • 12,373
  • 15
  • 63
  • 98
7

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.

spoulson
  • 21,335
  • 15
  • 77
  • 102
  • 1
    This seems to be the real answer, I also think it is has mainly habit/historical reasons, and the rest is just limitations of a code editor or bad fonts. – Mikhail V Jul 09 '16 at 20:51
5

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.

John Kraft
  • 6,811
  • 4
  • 37
  • 53
2

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

jammus
  • 2,540
  • 23
  • 28
2

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

mipadi
  • 398,885
  • 90
  • 523
  • 479
1

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.

Alan Hensel
  • 823
  • 7
  • 15