Input: Fonts for Code(input.fontbureau.com) |
Input: Fonts for Code(input.fontbureau.com) |
Besides personal preference, I think there are two main reasons people avoid proportional fonts: column alignment and two-space indents.
Two-space indents are an unfortunate trend in coding styles, because they practically mandate the use of a monospaced font to see the indentation. I use tabs for indentation, which let each developer adjust the visual indentation to suit their own eyes. Four-space indents are OK too.
I would love to see programmer's editors provide a way to control the amount of visual indentation that each leading space represents.
Column alignment of course is not possible with proportional fonts, but that's an easy problem to solve: don't do it. Instead of this:
void DoSomethingWithStuff(SomeReallyFancyTypeName thing,
string name
int count,
bool condition);
void DoSomethingWithStuff(
SomeReallyFancyTypeName thing,
string name
int count,
bool condition
);
This style also leads to much shorter line lengths as can be seen here, and it's easier to maintain: You don't have to realign things when you change the length of the function name or one of the type names, or when you add a parameter with a longer name than the ones you have already.
A case where column alignment is more useful is ASCII art in comments. I've experimented with using a monospaced font for comments and proportional for code, which solves that problem nicely. But I don't use ASCII art much myself, so I went back to proportional for everything.
I'm looking forward to trying out these fonts!
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 spaces and sooner or later, we're talking real bandwidth).
Then, there's the moment where we have to decide what those all those tabs (and sometimes spaces) mean, depending on the language, the layout rules, personal preferences, etc. For example, some people write Python with 2 spaces at the beginning of a line (which is plainly heresy). Others write it with 4 spaces (which is damnable blasphemy). Which is right?
And how many other languages are like this?(hint: any language in which layout is indented for any reason)
And concerning line length - what's the maximum allowable length before wrapping? You say 80, I say 132 (sometimes more), but I run terminal in a full-screen mode with 13-pt type, single-screened, never side-by-side.
Personally, I've learned my lesson. I'm waiting for editors to smarten up before I muck around with proportional fonts for code. Again.
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.
http://www.dafont.com/perfect-dos-vga-437.font
Screenshot:
Every year or so, I do the font dance and scour the web looking for clean bitmap fonts (I strongly dislike antialiased fonts, my opinion may change when I get a higher resolution screen) but always come back to uni_vga.
My experience so far is that I find this far harder to read. For reference's sake, I don't do parameter alignment in my own code (see Stratoscope's comment), but still find it easy to scan code in most-any monospace, probably because my eyes just know where to jump to all the time...
For all the words in favour of proportional fonts, I would venture that when the words on a page are in fact ultimately forming macroscopic symbols (identifiers), often with PascalCase or camelCase or underscore_words, uniformity no matter the characters used is perhaps a more useful feature than making the words easily comparable to those read in prose?
Even more than that (maybe it's something like "professional deformation" already, but I'm fine with it): I've considered using non-monospaced fonts automatically for stuff like LaTeX or markdown, or my own txt notes, but didn't find it pleasant enough. For all the european languages, anyway — typing japanese in vim is a bit painful for me and I don't know languages with more exotic writing system, be it arabic or hindi. I even hard-wrap natural language texts, which would be crazy using proportional font — and am glad I did so, when I want to see it through `less` on fullscreen.
I mean, it seems that for readability it would be better to emphasize the fact that they're asymmetrical - when looking at "foo(bar)baz" , it would be better if the parens would be a pixel or so closer to their inner contents; but currently "foo(bar" on most fonts looks as if the paren is merging with the initial text.
The same would apply for foo[bar]baz and foo{bar}baz.
(I’m a monospace addict, and I always switch between Source Code Pro, M+ 1m, and others. What I don’t like about M+ 1m is that it’s narrow, and the line-spacing in the web font is too small.)
""" <div><span class="highlight">M</span></div>
<div><span class="highlight">M</span></div>
<div><spam class="highlight">M</spam></div>
<div><span class="highlight">M</span></div>
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.
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.
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!
So you can get a nice preview of it if you like :)
(though, i think he uses 12pt, i use 13pt personally.)
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.
{
"line_padding_bottom": 2,
"line_padding_top": 2
}
However, even in code it is desirable to not add extra space to parenthesis, since “foo (bar” is certainly no less common than “foo(bar”. Basically, the font would have to automatically adjust depending on whether or not a space is in front of it to treat both of those cases appropriately. (I think that’s possible with current font formats, so there is likely no technological hurdle to this.) However, that might not be desirable since it might make “foo (bar” and “foo(bar” easier to confuse.