Programming Fonts | Hacker News Reader

Programming Fonts

programmingfonts.org

57 points_zhqs16 comments

While a useful utility for quickly discerning some macro-level differences between fonts there is a catch. For bitmap fonts (e.g. Cozette) the rendering will be comparatively terrible once vectorised into ttf, otf, woff for the web -- since the point of bitmap fonts is to be pixel-sharp.

To me, the two most important symbols in a programming font are the 0O vs 1l.

I've been using the same 2 fonts for maybe five years and recently got confused looking at a lowercase "L" or a one (1).

Cool website.

See also https://coding-fonts.css-tricks.com/ for non open source ones.

Rendering is off. Same font, size, code and colour scheme looks different from how it does in VSCode

Where is "Monaco" font?

macOS: /System/Library/Fonts/Monaco.dfont

Yes, rather a glaring omission. I've just wasted the best part of a day trying-out different fonts on my Mac for IntelliJ, iTerm2 and MacVim. Menlo came close but didn't quite match Monaco for ease of reading paragraph text as well as code. Started with it in 2003 and haven't found anything to match it since.

On a tangential note, I have been wondering recently why programmers and the code editing software they normally use stuck to the typewriter/punchcard mindset as far as the code formatting and the choice of fonts are concerned...

You certainly find some people who don't use monospaced fonts in their editors/IDEs, but of course while that may make for better readability on the line, you lose the consistent indentation (matters more for some languages than others, Python e.g.)

There are some indentation styles where you don't lose consistent indentation in that situation.

You don't lose consistent indentation at all with proportional fonts (N-leading-spaces provides a consistent horizontal position.) You do lose consistent non-indent alignment (N-leading space plus M-other characters doesn't consistently result in the same horizontal position for constant N+M, or even constant N and M, M>0.)

For python, this is not a problem, as consistent indentation is important, but alignment is not (I use proportional fonts for Python and YAML all the time, and the only problem is how annoying the ASCII Art labels someone put in some of our YAML are without consistent alignment.)

And better readability is more important than ascii art.

If you're talking about monospace fonts well, eliminating layout variation eliminates noise. Spacing is predictable, so that gives you hints at a glance that your code is correct, line from line.

Entirely difference reasons for equally spaced letters.

Typewriters had no way of adjusting kerning pairs. The space between ho and lo are different in proportional fonts. These are called kerning pairs. So, it was mechanically easier to make letters of same width.

Code is monospaced for many reasons others have replied here.

> why programmers and code editing software they normally use stuck to the typewriter/punchcard mindset as far as code formatting and the choice of fonts are concerned...

Because computers used to display exclusively in monospaced fonts and coding adapted to that, including use of character position in lines for visual alignment. There've been more recent moves away from that (both elastic tabstops and indent-only-and-never-align are approaches) but they haven't become universal so if you ever deal with code that isn't from a tightly controlled group with practices against position-based-alignment, you are going to run into code that uses it.

Because Python.

Reply on news.ycombinator.com