Live data from Hacker News

Input: Fonts for Code

input.fontbureau.com

21–30 of 44 posts

Re: Input: Fonts for Code

#21
post #3
post #2

Totally subjective opinion, but yet to see something beat Consolas.

I actually prefer Ubuntu Mono over Consolas or Inconsolata but fonts are a very subjective thing. :)

The biggest problem with Ubuntu Mono is the rather small size of its punctuation, especially dots have been nearly invisible for me. Other than that, the Ubuntu family of fonts are fine indeed.

Re: Input: Fonts for Code

#22
post #13

On the info page: """ M M M M proportional fonts can make it easier to spot typos """ The example given demonstrates that a certain subset of typos can be caught using proportional fonts, but not all. If a word has too many or too few characters in it, I think you are more likely to spot it utilising a monospaced font. EDIT: the quote has been made more legible.

[deleted]

Re: Input: Fonts for Code

#23
post #3
post #2

Totally subjective opinion, but yet to see something beat Consolas.

I actually prefer Ubuntu Mono over Consolas or Inconsolata but fonts are a very subjective thing. :)

One reason I like Ubuntu Mono is that it supports a large number of Unicode characters. When I was using Inconsolata, a non-ASCII character would be replaced with a glyph from a different font (usually being a bit too big in gnome-terminal). I'm glad that there's a variety of high-quality open fonts to choose from!

Re: Input: Fonts for Code

#24
Just the Mono family alone is excellent. There are a number of different weights available, each with italic and bold variants, and the repertoire of glyphs is extensive.

I enjoy condensed fonts like Pragmata Pro (which I highly recommend), and this appears to be one of the few viable alternatives I've seen. Merits a week-long test-drive, I think.

Re: Input: Fonts for Code

#25
I have been having a love affair with Source Code Pro, thin weight, at about 14pt, using Solarized Dark color palette.

There's something refreshing about it, it's nice, big, clean, and LEGIBLE. I use it for my IDE and terminals and there's no turning back.

Highly recommend everybody check out Source Code Pro!

Re: Input: Fonts for Code

#26
Looks nice, I've switched my terminal to Condensed and works great.

I unfortunately can't use it in my main IDE's as both PyCharm and PHPStorm have bad aliasing on Linux fortunately solved by Terminus which doesn't require it.

Re: Input: Fonts for Code

#27
post #25

I have been having a love affair with Source Code Pro, thin weight, at about 14pt, using Solarized Dark color palette. There's something refreshing about it, it's nice, big, clean, and LEGIBLE. I use it for my IDE and terminals and there's no turning back. Highly recommend everybody check out Source Code Pro!

I just recently switched. Turns out, this is the same font that Codegansta uses, as seen here: https://gophercasts.io/

So you can get a nice preview of it if you like :)

(though, i think he uses 12pt, i use 13pt personally.)

Re: Input: Fonts for Code

#28

Just the Mono family alone is excellent. There are a number of different weights available, each with italic and bold variants, and the repertoire of glyphs is extensive. I enjoy condensed fonts like Pragmata Pro (which I highly recommend), and this appears to be one of the few viable alternatives I've seen. Merits a week-long test-drive, I think.

Actually, it looks a lot like PragmataPro: https://www.dropbox.com/s/7c5yifw5saip3ae/pragmata_vs_input....

Re: Input: Fonts for Code

#29

Wow, I never thought I would see proportional fonts specifically designed for coding. I've coded almost exclusively in proportional fonts for over ten years. The font I use the most is Georgia. It makes code easier to read and more pleasing to the eye, just like any other text. Besides personal preference, I think there are two main reasons people avoid proportional fonts: column alignment and two-space indents. Two-…

I would say that the problem is "SomeReallyFancyTypeName" where you've created a ridiculously long type name (one of the reasons I avoid Windows programming at all costs). That aside, editors don't handle tabbing very well. It's far more space-efficient to insert two tabs instead of 8 spaces, but space and bandwidth are so cheap these days, no one can be arsed to fix what is viewed as a minor problem (use enough spac…

Thanks for the comments. You're right, "SomeReallyFancyTypeName" was a bit of a strawman on my part. But even with shorter type names you still have the same problems if you use column alignment. I actually gave up column alignment long before I started using a proportional font. I just found it to cause more headaches than it was worth.

You mentioned that "editors don't handle tabbing very well". All the editors I use most frequently - IntelliJ IDE, Visual Studio, MonoDevelop, Komodo, Sublime Text, UltraEdit - handle both tabs and proportional fonts without any problem, so that hasn't been an issue for me. I'm curious to know what editors have trouble with tabs.

Anyway, I try not to worry too much about tabs vs. spaces. My only real objection is two-space indents. That's just not enough for many people including myself.

Of course many editors don't support proportional fonts, but that doesn't cause a problem for those of us who like to use proportional fonts in the editors that support them. It's really easy to write code that is equally readable in a monospaced or proportional font.

Regarding the line lengths, my coding style lends itself to very short line lengths, as shown in the example above. I think that helps give some freedom to use wider indentation.

Re: Input: Fonts for Code

#30
post #14

Earlier quoted context omitted.

Fonts do it because outside of code there is just always a space character inserted before every parenthesis. Adding additional space inside the parenthesis character would just increase that space, something that is not desirable.

The topic is developer-oriented specialized fonts - so there is no such thing as 'outside of code', and in a monospaced font no space can be added since the width is fixed - so my question was about shifting the parenthesis towards the 'inside' within that width.

even in code 'foo (bar' is as common as 'foo(bar' and because parens tend to be narrow -as opposed to W or M- moving it one direction or the other would leave a -taste vary but- weird looking gap of white space. It would also through off visual alignment in columns, which is basically the only argument monospaced fonts have going for them.
Post reply on HN