Hacker News Reader

Comment by tjr | Hacker News Reader

Stroustrup's C++ book stands out in my mind as one of the few programming books that I own (possibly the only one) that does not use a fixed-width font for code examples, and I find it very unpleasant to look at. Accordingly, I have avoided variable-width fonts for programming altogether.

But the font in that book is by no means the only variable-width font. Could anyone here recommend a variable-width font that you have had good experience coding with?

View on HN

It was (is?) pretty fashionable in European programming books for some time. For example, all of Niklaus Wirth's books use variable-width fonts. I also find it unpleasant or even irritating at times.

It's useless to compare programming languages to natural languages. Programming languages are formal languages and require some amount of precision for proper tokenization and parsing. If you misspell a word in English, or forget to capitalize something, or miss a space, people can still read it; if you do the same thing in a programming language, you often get an error. Typographic errors in code stand out better in a fixed-width font than they do in a variable-width one.

“Typographic errors in code stand out better in a fixed-width font than they do in a variable-width one.”

That’s a bold assertion. I would be very interested to see a study that demonstrates this.

I'd like to see a study, too. Unfortunately, I don't know of any.

I do, however, vaguely recall an ergonomic study finding that it's easier (or at least faster) for humans to read text in variable-width fonts. I'll try to find a reference when I get off work.

That being said, code isn't the same as text. My own experience has been that a missing or wrong character is easier to notice with a fixed-width font (especially narrow characters), and that extraneous or missing spaces are less obvious. Where those things don't matter too much for human readers, they do matter for computer readers. It's obvious to a human that BubleSort is probably supposed to be BubbleSort, but in a more formal setting there is a distinction.

My concern for using a variable-width font is knowing how deeply indented I am at any point. With a fixed-width font, I can simply look up and see how many characters deeper I am compared to the previous line. I don't know how that would work with a variable-width font. I'd probably have to move my cursor back and forth, which would be a pain.

Spaces or tabs have the same width within a font. Indentation at would work the same. You could even use tabs to line stuff up.

Plan 9 uses a variable width font for their editor by default, and I never really noticed any significant differences for writing code in it.

I don’t understand what you mean—it doesn’t really matter how many characters or columns you’re indented, and can’t you discern depth visually in the same way regardless of typeface?

I've been using DejaVu Sans (proportional) for programming (including Python) for the last few months, and found it very easy to get used to. There are just a few glyphs that could be adjusted to line up better (closing braces in JS/PHP are a few px off), or in the case of quotation marks, two single quotes render the same as one double quote. I've started editing DejaVu (it's OSS) to correct these small number of issues, I don't think they are insurmountable.

Well I'm not sure that it's actually a problem in practice but with a W taking up two ' ' spaces I can imagine a scenario where you over correct and end up in the wrong level.

It does if you're using Python...

No, it doesn’t. Your indentation level matters, but provided your indentation is consistent, it doesn’t matter whether you use tabs or spaces, and the notion of “column” isn’t relevant to proportional-width fonts. If you’re worried about invalid indentation hiding from you, don’t use spaces for indentation with a proportional font—it doesn’t make sense anyway.

It matters more when you've got a statement broken over multiple lines. If you've got a function which takes a lot of arguments for example, lining them all up vertically can make the code a lot easier to read. This can be difficult or impossible to do with a proportional width font (and would almost certainly look very strange to anyone else looking at the code in a fixed-width font).

That's understandable. I agree that tabs would work much better than spaces with a proportional font. However, in the case of Python PEP 8 states that you should use 4 spaces. Not doing so will make it very hard to collaborate with other devs.

It's not that I think that proportional fonts couldn't work (even with python) It's just that I have concern about visually assessing indentation. Maybe it's time I try one and find out.

PEP8 recommends spaces: http://www.python.org/dev/peps/pep-0008/

I think part of the problem is that C++ was not designed with proportional-width typefaces in mind, but I’ve had good experiences with broadly spaced sans-serifs, even the basics such as Arial Unicode and Lucida Sans Unicode. http://programmers.stackexchange.com/questions/5473/19828#19... suggests Ubuntu Sans, which I think looks excellent. I think serif typefaces look nicer for more mathy languages such as Haskell.

I remember reading one of Douglas Hofstadter's books - Metamagical Themas - and liking the bold Helvetica font he used for all the Lisp code. But I doubt he coded with it...

I think Lisp is much more amenable to proportional fonts because it relies more on parentheses than indentation for structure.

Each space in a proportional font is a set width, so the indentation structure is just as clear as with a fixed width font. Am I missing something? I can only imagine a problem if there is a mix of tabs and spaces..

It's not about getting adjacent lines with equal depth to line up. Its when you are indenting, and try to put yourself four spaces in. In a fixed-width font, you can just line yourself up with the fourth character of the previous line. In a variable width font, it's harder to tell how many spaces in you've gone.

Any reasonable editor can be set up so that the tab key will take care of that: ideally, you would also indent with tabs not spaces, and then you could set any tab width (in pixels, or better, points) you wanted and your code would still look right.

The problem comes if you want to left-align some code with a character on a previous line which is not the first non-space character. People often do this for run-on lines, for instance. Then there's no guarantee that spaces or tabs will align you correctly.

The ideal solution to the latter problem is: (i) Don't Do That, Then. (ii) If you want to align code in some carefully prescribed circumstances such as run-on lines, your editor should handle it for you when it displays on the screen (and the alignment hints need never make it into the saved file).

Ah, ok. This problem doesn't manifest in emacs, as the tab key indents you correctly by 4 spaces in most modes. I can't imagine it's much of a problem to line yourself up with the first character of the previous line and press the spacebar 4 times though.

I've not read Metamagical Themas, but your words remind me that one of my favorite programming books, The Little Schemer, does in fact use a variable-width font for the code.

It's not programming, but lhs2TeX is a positive example of typesetting code with proportional fonts.

http://people.cs.uu.nl/andres/lhs2tex/

It goes to heroic lengths (writing polytable.sty) to preserve alignment in the input program, not just indentation.

Reply on news.ycombinator.com