Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It looks like these are all monospaced fonts.

I realize that most programmers use monospaced fonts, but I personally find proportional fonts to be much more readable and pleasing to my eye. I would be really interested in a similar font comparison that included proportional fonts that are suitable for programming.

Right now my favorite is Trebuchet MS. This renders beautifully on the high-DPI displays I use, and it has easily-distinguished glyphs for the common mistakables like Il|. Its tilde is not very good though, so I used a font editor to swap in a better one.

But I'm always interested to hear about other options!

When I do have to use a monospaced font (e.g. in a terminal window), Liberation Mono is my favorite. Definitely worth a look if you like monospaced fonts.



Verdana used to be my go to proportional font when I was doing Java. Helped with long variable names and long horizontal lines. My buddies thought I was nuts, but I found it very legible.

These days my eyes are dimming, so I dislike skinny fonts. Now I use DejaVu Sans Mono in _bold_ exclusively. Every now and then when HN does a programming font post, I try out different ones, but I always end up going back to DejaVu Sans Mono Bold.


If you like bold fonts, try Terminus bold at around 16pt.

Also, the old VGA font is surprisingly nice and legible. Can be had here:

https://int10h.org/oldschool-pc-fonts/fontlist/


Like you, I'm not as young as I used to be. So I'm with you on the skinny fonts! One of my biggest pet peeves is web designers who think font-weight: 300; is a good idea.

You might take a look at Trebuchet MS. One thing I like about it is that the strokes are nice and fat. At least on my high-DPI displays; haven't checked on a low or medium DPI display.


+1 for Verdana. Been using it for 3 years now. Couldn't be happier.


For those who like Verdana, check this out.

https://www.microsoft.com/en-us/p/verdana-pro/9n8d67vhhdc2

Coincidentally, I wonder if the license allows it to be downloaded and installed on other OSes, like the old "Microsoft core fonts" package that included Verdana.


>Coincidentally, I wonder if the license allows it to be downloaded and installed on other OSes, like the old "Microsoft core fonts" package that included Verdana.

It doesn't look like it.

The Microsoft core fonts EULA (https://web.archive.org/web/20091208063245/http://www.micros...) says things like:

> You may install and use an unlimited number of copies of the SOFTWARE PRODUCT.

> You may reproduce and distribute an unlimited number of copies of the SOFTWARE PRODUCT; provided that [they're verbatim, include the EULA, aren't distributed for profit]

> You may not rename, edit or create any derivative works from the SOFTWARE PRODUCT, other than subsetting when embedding them in documents.

> You may permanently transfer all of your rights under this EULA, provided the recipient agrees to the terms of this EULA.

So you can distribute and install them. You have to take some care, but you don't need to involve Microsoft, and you're not bound to the systems they were originally intended for.

The Verdana Pro license (https://www.microsoft.com/en-us/servicesagreement/#STANDARDA...) says things like:

> You may install and use the application on Windows devices or Xbox consoles [...]

> [You may not:] Work around any technical limitations in the application.

So it's very limited.


Man, Verdana gives me flashbacks of late-'90s messing with html. If it hits the typical 20-years fashion rota and gets cool again, I'll feel really old. It's the flannel shirt of fonts.


I'm curious to know how you started using proportional fonts for coding. All of the tooling for writing code defaults to monospace, so what started you coding in a different style?


For me it was efficiency of reading. It is proven that proportional, serif fonts read significantly faster (17%) [1] or [2] (6.1%). Also, in my opinion, scanning is much faster.

This makes sense: our eye uses the top and bottom of words to ‘key’ the word. Use proportional and you add information to this system.

[1] https://blog.codinghorror.com/comparing-font-legibility/

[2] https://journals.sagepub.com/doi/pdf/10.1177/001872088302500...

(edit: add references to research)


One of the early proponents of using proportional fonts for code was Bjarne Stroustroup - his "The C++ Programming Language" books all do that, and he briefly explains it in the intro as being more readable, and urges the readers to give it a go. I wasn't convinced, personally, but the idea was already around then.


The Smalltalk system also used proportional fonts, and predates that book by many years.


The first edition of the C++ book was in 1985, so that is roughly the same timeframe as Smalltalk-80 getting popular.


Using a proportional font is also common (recommended) when programming in Bertrand Meyer's Eiffel or Niklaus Wirth's Oberon.


IDEs defaulting to proportional fonts are uncommon but not unheard of. I think BlitzMax or BlitzPlus uses proportional fonts by default.

Coding using proportional fonts is easy to get used to, and it has its proponents. The key is: indent, don't align, and use TABs.


Thank you for your curiosity! My other comment may answer the "how I started" question:

https://news.ycombinator.com/item?id=18958335

But one thing I'm wondering about:

> All of the tooling for writing code defaults to monospace...

Do you have an example of such tooling? One that I'm familiar with is Google's coding standards, which are obsessed with lining things up in ways that only work in monospaced fonts. Is that the kind of thing you're thinking of, or something else? Thanks!


Optimize all the things. Noto Sans is my current favorite.


I also use proportional fonts. No problem with coworkers in either JavaScript, Ruby, Python, Elixir. I'm using DejaVu Sans Book on Ubuntu in Emacs.

People are always puzzled when they learn I'm not using a monospaced font, think it's impossible but agree that it's much more readable. Then keep using their monospaced fonts.

Actually, nobody likes to read books or blog posts printed with monospaced fonts, right? There is no reason to do it with code.

Alignment like this

   short        = 1
   much_longer  = 2
is lost but it's not really important. I think it's also against Python's style guide and for sure it doesn't survive the Elixir formatter (I checked this now.)


Curious. How do you line things up?


> Curious. How do you line things up?

I don't! :-)

I spent many years lining things up. I would write code like this:

  foobar(firstArg,
         secondArg,
         thirdArg);
(For the sake of discussion, assume that those arguments were too long to just put it all on one line, so you would naturally want to use multiple lines.)

Then when I realized that 'foobar' wasn't such a good name, I had to re-align all the code:

  doTheRealThing(firstArg,
                 secondArg,
                 thirdArg);
At some point, maybe 20 years ago, I got really tired of this.

So I thought, "what if I just use indentation instead of trying to line things up in columns?" Which led to this:

  foobar(
      firstArg,
      secondArg,
      thirdArg
  );
And when I renamed the function, I didn't have to move everything around any more:

  doTheRealThing(
      firstArg,
      secondArg,
      thirdArg
  );
Instead of every line changing, only one line changed. [1]

After I adopted this style, I noticed that the code editor I was using at the time supported proportional fonts, so I got curious and tried one - I think it was Verdana.

And sure enough, the code was just as readable as it was before.

If you don't line things up in columns but instead just use indentation, then a proportional font works just as well as monospaced.

[1] Some will say "just ignore whitespace in your VCS diffs, and this won't be a problem." But I want to know about whitespace changes, just like I want to know about any other change.


Not a fan of proportional fonts for coding, but the point about refactoring affecting indentation is well worth reiterating. If you have ever dug through source control history, you know that there's value in not touching the lines unnecessarily. Unfortunately, most common coding styles that advocate lining things up do this wrong, such that a single rename can affect several times as many lines that are completely unrelated.


This does force you into a style where lists of indented things require a new line - not necessarily bad, just an observable side effect, and can cause problems if you share a codebase that maintains a different style.


Very true, if you are working on an existing codebase, you ought to follow whatever style it uses.

Interestingly, one of the reasons sometimes cited for using alignment is that it reduces the number of lines of code needed for a statement or expression. But as often as not, I've seen that backfire because the code gets pushed farther and farther to the right, eventually resulting in more lines of text instead of fewer.

I posted an example from the Rust/Servo code in another comment:

https://news.ycombinator.com/item?id=18962177

This code in their old column-aligned style is actually one line taller than the indentation style they recently switched to.


> I had to re-align all the code:

Cannot you just have your editor do that for you?


It was about 25 years ago that I stopped using alignment, and the editors I was using didn't have that kind of auto-formatting.

But there was more to it: I realized that I didn't like column alignment any more. It didn't make the code any more readable, and in many cases it made it less readable.

A more recent example of a group that abandoned alignment is the Rust and Servo teams at Mozilla. Their code style used to look like this:

    let mut rewrites = try_opt!(subexpr_list.iter()
                                            .rev()
                                            .map(|e| {
                                                rewrite_chain_expr(e,
                                                                   total_span,
                                                                   context,
                                                                   max_width,
                                                                   indent)
                                            })
                                            .collect::<Option<Vec<_>>>());

A year or so ago they changed to a purely indentation-based style:

    let mut rewrites = try_opt!(
        subexpr_list
            .iter()
            .rev()
            .map( |e| {
                rewrite_chain_expr( e, total_span, context, max_width, indent )
            })
            .collect::<Option<Vec<_>>>()
    );
They found this style to have advantages over alignment, perhaps for some of the same reasons that I prefer it.


I would suggest that using elastic tabstops¹ is the only reasonable system for doing that. Sadly, the industry seems to be stuck in a local maxima where the simultaneous jump to both using proportional fonts (which would be better) and using elastic tabstops for alignment (which would be easier), constitutes too large of a distance to bridge in a single leap, and either one by itself isn’t worth the effort.

Of course, if you already have made one of these two jumps, it should be a no-brainer to make the other one as well.

1. http://nickgravgaard.com/elastic-tabstops/


I think it's even worse: the big problem with elastic tabstops is that you can't just adopt them on your own. You are requiring everyone who reads your code to use them if they want to see it formatted properly.

Proportional fonts are different. Anyone can use them without interfering with readability regardless of the fonts and editors that others use. If you look at my code, you will never know whether I wrote it in a proportional font or a monospaced font.


> You are requiring everyone who reads your code to use [elastic tabstops] if they want to see it formatted properly.

It is not quite as bad as you make it sound.

While editors which haven't yet implemented the elastic tabstops mechanism may not align some text properly in files where tabs were used with elastic tabstops, the problem isn't that bad. All leading tabs (indentation) will be okay, and the chances of text not aligning correctly diminishes as the width between tabstops increases.

http://nickgravgaard.com/elastic-tabstops/


Not OP, but I use Verdana in Java.

Most things line up perfectly fine i IntelliJ.

I have had someone on my team with an itch for lining up variable assignment. That was the one thing that looked off.

  int abc              = 3
  int defg             = 4
  int bigTestVaribale  = 6


(Another proportional font user) These cause problems in diffs as well. Change bigTestVarible to bigTestVAriable and all three lines show as changed.

Nevertheless, for teams that insist, the auto code formatter makes it look ‘nice’ for them.

Personally, I think vertical alignment apart from indentation is a mistake for more than these reasons. It implies a structure where there is none.


Verdana and Optima are my go to fonts. Have used proportional fonts since 2010, with close to no problems, save the occasional newbie who aligns assignments or types.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: