I'm surprised Liberation Mono[1][2] (similar to the Deja Vu font) is not on the list or the bitmap font, Dina[3]. I end up using Liberation Mono much more nowadays (which is similar to Dina), since bitmap fonts don't have support in a lot of development tools and Dina has no real UTF-8 support. However, Dina was my first real "programming font" I used and still love it where I can use it.
It's hard for me to give you an exact comparison (because I'm not an OSX user and have never used Menlo), but I can give you an idea based on a comparison to Deja Vu (on both Linux and Windows 7). Some of my reasons are preference (what looks better) and some are factual (like spacing).
Liberation Mono is a more vertically compact font, but I consider it just as readable as Deja Vu. I can fit around 7 more lines on my 1920x1200 monitor with 13pt Liberation versus 12pt Deja Vu. Deja Vu just takes up way more space than it needs to and (my opinion) does not make it anymore readable than Liberation or Dina.
I generally dislike anti-aliasing/smoothing on fonts when writing code in certain editors/ides (looking at you Intellij Idea). I don't mind it elsewhere, but Java just sucks at rendering fonts with its generic anti-aliasing scheme. Since I dislike it in Intellij and I use their IDE quite a bit for Android/Java, Python, JavaScript or PHP, I disable the Java anti-alias setting and most fonts tend to look bad that way as they're designed for smoothing.
Liberation though looks great with little to no distortion even without anti-aliasing enabled. I would have stuck with Dina (similar to it) since bitmap fonts do not get smoothed out by the OS or IDE, but many editors do not support bitmap fonts and the lack of UTF-8 support with Dina is a letdown as well. It's still a great font, just the tools I use end up being more important than the font itself.
Compared to Deja Vu, Liberation has less distortion glyphs without smoothing enabled and much more readable. The real downside to Liberation Mono is the 0 has just a dot in the center of it instead of a full slash unlike Menlo (doesn't bother me as I can see it, but I would prefer a slash).
Just for reference and because pictures give a better idea than my own preferences, here's a comparison:
Yes. A proportional font for programming. In the beginning I hated tabs and white space, until I just got used to it. Now it's much easier to read my own code. Words jump out of the text because spaces are spaces and "i" doesn't make me doubt for a split second where the word starts and ends.
I'm another proportional font programming fanatic. I have tried just about every plausible monospaced and and proportional font, and the one I keep coming back to is Georgia. On a high-enough resolution display (125DPI or better) with ClearType, I find it easier to read than Verdana or other sans-serif fonts.
Georgia is a bit of a radically-proportional font: even the numbers are proportionally spaced! Most proportional fonts have monospaced numbers. I think I would probably like monospaced numbers, but I do like Georgia enough that the proportional numbers don't bother me.
I find the same benefit you do: I have an easier time reading my code (and other people's code too). There's a subtle benefit as well: it's completely removed the temptation for me to look for column alignment when there's no need for it. I think monospaced fonts trick our eyes into seeing, and seeking out, vertical patterns that don't really need to exist.
Since as I mentioned in another comment, I just don't do column alignment any more (indentation only), that takes away the old arguments about "tabs for indentation and spaces for alignment" and such. It doesn't matter if you use tabs or spaces for indentation; the code will look fine either way. And there's no column alignment to get messed up.
I should also mention that I don't have any beef with people who prefer monospaced fonts. I do have a beef with coding standards that only work in monospaced fonts because of column alignment and similar column-oriented formatting tricks.
> Most proportional fonts have monospaced numbers.
Most fonts that are worth their money come with monospaced and proportional numbers in both lining and old-style forms. Those can be chosen via OpenType features but I fear most code editors don't allow choice in that matter.
At risk of sounding blunt, I do want to ask: have you tried several fixed-width fonts, or have you just used whichever is default on your system? In my experience, there seems to be no issue seeing where there is a space (not even for a split second) with well-designed fixed-width fonts. In fact, for me, it's more apparent, as spaces tend to be wider in fixed-width fonts, being the width of the widest character.
I tried a bunch yes, and was fairly happy with them. Then I read about using proportional fonts for programming and just had to try it. It was a tad weird in the beginning but soon felt much more natural.
+1 for proportional fonts. I'm a long time user of Times New Roman in Xcode. I keep TextMate and my terminal monospaced, but for Objective C proportional fonts work perfectly once you adjust.
I kindof makes sense because ObjC methods are so wordy, that you would want a font aimed at readability rather than symbols.
How do you actually code effectively with a proportional font?
Without a monospaced font, column cut, copy and paste operations are effectively eliminated (as nothing lines up vertically) and that is one of the programmer editing constructs I use the most.
Lack of column editing always drives me back to monospaced fonts in the end, too. I like the proportional look, but column operations ate just too convenient.
(Perhaps I need to make an emacs keyboard shortcut to toggle font type at the press of a key. Then i could quickly switch to monospaced for my rectangular operations. That might work. Wouldn't help for Xcode or Visual Studio though.)
I think it was Eclipse that switched to a Monospace font when entering column selection mode. While having a mode and not a quasi-mode for that operation is highly questionable to me, the automatic switch is a very nice touch. Especially to those who usually use a proportional font.
I am very curious: where (programming language) and how do you use column editing? I must be missing out on some huge productivity booster, but I think having automatic code layout makes this feature as good as 100% superfluous.
you are writing "cap_capget", you could write three lines,
effective
inheritable
permitted
And now, select in block mode the text you typed, click copy.
Then select blank column to the right of any of the text, and type
= cred->cap_
once you finished typing that (since you typed in block mode, it typed that across all 3 lines at once), now press your ctrl-v . and then type semicolon. Done.
As a reference point, I'm using Windows 8 on a moderately high-density display for a Windows laptop, at around 140 DPI. I'm old, with less than perfect vision, but it corrects well with my single-vision computer glasses.
My favorite font these days, as I mentioned elsewhere, is Georgia. I just find it so easy to read.
Other proportional fonts I've tried for coding and liked fairly well are Verdana, Cambria, Rockwell, and Source Sans Pro.
The best thing, of course, is to try a few and see what pleases your eyes.
I didn't realize it until you mentioned it, but Komodo has a similar feature. You can select monospaced or proportional for any syntax element. I think I will try putting comments in monospaced and see how it works out.
My first summer job was back in 1969 at a company in Phoenix called TransData.
We had a program on the Sigma 5 called Ferret, which would copy data and read and punch paper tapes and stuff like that.
You'd end up with a lot of rolls of paper tape with your various programs and files on them. The problem with these rolls was knowing which was which.
Traditionally you would leave a few inches of blank tape at the beginning and write the file name on it with a pen. When you roll up the tape and put a rubber band around it, you've got the filename right there. This did get a little tiresome though.
The paper tape for the ASR33 stored a byte at a time - eight holes that you could punch or not punch before the tape advanced to the next row. So I updated Ferret to punch out the filename in an 8px font that you could read after you rolled the tape up.
And I'm almost certain it was a proportional font!
Interesting, but how do you know if you passed the column 80? how do you work when the coding standards mix tabs and spaces (like tab for indenting, spaces for multi-line aligning)?
Those are coding standards designed for monospaced fonts. They work poorly with proportional fonts, but there is a simple solution: abandon those standards.
With regard to indenting vs. column alignment, don't do column alignment. Code is an outline. It's not a spreadsheet. Column alignment is not beneficial in most cases, and it wreaks havoc with source control diffs. Is it really better to code like this:
double someFunctionName( int index, // counts things
SomeType secondParamWithStuff, // fancy object with stuff
SomeLongerNamedType third ) // whatever
instead of this:
double someFunctionName(
int index, // counts things
SomeType secondParamWithStuff, // fancy object with stuff
SomeLongerNamedType third // whatever
)
Now sure, the second version may look a bit sloppy if you're used to the first, but it has several real advantages:
* Much less horizontal eye movement
* No eye tracking across wide swaths of whitespace
* Changing one name doesn't require reformatting the whole thing
* Since you don't have to reformat, it doesn't generate unrelated diffs
* It works equally well in proportional or monospaced fonts
Oddly enough, many years ago I switched to the second style, not because I was using a proportional font at the time, but because I was really tired of reformatting multiple lines of code just because I'd refactored one variable or type name.
And then some time later I tried a proportional font. My code looked fine in the proportional font, and it was still just as readable in a monospaced font.
WRT 80 columns or whatever your limit is, I just don't worry about that. I generally keep my lines quite a bit shorter than that, but if a particular piece of code is more readable with a longer line, I don't sweat it.
> Code is an outline. It's not a spreadsheet. Column alignment is not beneficial in most cases
But there are many cases where code works best as a spreadsheet.
For example any time you need to initialise an array of structures, that is best viewed using a grid like pattern.
> but because I was really tired of reformatting multiple lines of code just because I'd refactored one variable or type name.
Any decent editor with smart indenting should eliminate most of that effort.
Also if the editor is scriptable editor, it should be possible to create a simple script to semi-automate the task.
> But there are many cases where code works best as a spreadsheet.
Indeed, that's true, and I don't mean to be too much of a proportional font fanatic. Even if I try to avoid coding styles that require monospaced fonts to be readable, there are always cases where it helps to get a monospaced view of the code.
One feature I really like in an editor is an easy way to switch between proportional and monospaced views. The best support I've seen for this is in Komodo [1]. Like many editors, Komodo supports multiple themes of font face/size/colorization/etc. What it does differently, though, is that each theme has two font selections, a proportional font and a monospaced one. So you can pick your favorite for each, and then choose whichever works best for the particular code you're looking at right now.
Oddly enough, out of the box Komodo doesn't give you a keyboard shortcut to switch between proportional and monospaced, but it's easy enough to add a keyboard shortcut for this. (In the Key Bindings dialog, look for User Interface: Use Fixed/Proportional Font.) I have this set to Alt+O which is unused in a default Komodo installation on Windows, and it's easy to remember because "proportional/monospaced font" has a heck of a lot of "O"s in it. :-)
But when I do use an editor that only offers monospaced fonts, it's not a terrible thing. I use your excellent Zeus IDE [2] for my Go coding and it's a pleasure to work with. Sure, I miss my proportional fonts, but having the integrated debugger and other goodies for Go makes it well worth it.
> I use your excellent Zeus IDE [2] for my Go coding and it's a pleasure to work with.
Funnily enough I'm the author of the Zeus editor. Glad to read you like using it :)
> Sure, I miss my proportional fonts, but having the integrated debugger and other goodies for Go makes it well worth it.
Over the years many Zeus users have asked for proportional fonts so you’re not the only user who misses them.
The reality is many years ago, Zeus was designed with only mono-spaced fonts in mind.
At that time, the simple rule of knowing all characters are the same width and height seemed to greatly simplify the design of the editor.
And once that design decision was made it's amazing how many places in the editor code that rule then ends getting coded, making it very difficult to change :(
Given the time again I think the underlying design would be different.
> Those are coding standards designed for monospaced fonts. They work poorly with proportional fonts, but there is a simple solution: abandon those standards.
Yes, you suggested abandoning coding standards designed for monospaced fonts, specifically maximum line length. While most programmers use monospaced fonts, you are bound to clash with someone and make their lives harder by dropping some standards.
Don't read too much into that part of what I wrote; I said it poorly. I'm quite aware that most people use monospaced fonts, and my code has to be just as readable in a monospaced font as in a proportional font, or it's no good.
I don't like excessively long lines any more than anyone else does, and I do pay attention to the column numbers. I just don't worry about them much, partly because my coding style naturally tends to produce shorter line lengths.
Compare:
function niftyExampleFunction( niftyExampleParameter, // nifty comment
anotherNiftyExampleParameter ) { // another comment
doStuff();
}
vs.
function niftyExampleFunction(
niftyExampleParameter, // nifty comment
yetAnotherNiftyExampleParameter // another comment
) {
doStuff();
}
That's a line width of 84 vs. 56 for the same code. Fair enough?
Just another thought that I forgot about last night. You were asking about teams and maximum line length. As I think back, most of the teams I've been on in recent years just weren't very worried about that. We all kept to short lines as a matter of readability, but didn't have any particular hard limit if a particular piece of code happened to be more readable with longer lines.
Of course this was long after the days of 80-column Teletypes, and we were mostly using various GUI editors that didn't have a hard restriction on line length.
But back in the days when I coded on a Teletype, I definitely kept all the lines shorter than 80 columns! :-)
One critique I have of elastic tabs is that you need to read the whole document to know how to lay out just what you see before you. That's not an issue with files up to a couple of thousand slocs, but I've had to work with 60ksloc autogenerated source files and waiting for one of those to be parsed and laid out would be a pain in the ass.
I don't use a proportional font like the OP but graphics art stuff like that is best handled by computer.
For example if you do sysadmin scripts in perl and edit with vim and have perltidy installed, its more or less just (esc) :%! perltidy (enter) and it looks beautiful.
Gave up on 80 columns a couple years ago. Haven't looked back much.
First off I'm a student. Though the last summer job I had people didn't really care that much. Tabs/spaces doesn't really matter much. 80 char width also never been a problem. If it makes sense to have it on a 150 char line, then so be it. If it makes sense to split it up, then do that.
The only time I ran into length problems was when I was asked to print my code on A4 paper for an exam.
Verdana is great for alphanumeric characters, and a little enhancement of the scope characters/operators makes it perfect for programming: http://i.imgur.com/KCKtUR1.png
Looks interesting, can you link it somewhere please? You've posted this several times but have yet to share. I'm not quite sure of your legality concerns, Verdana can be downloaded in tens of thousands of sites by simply searching Google. Even Microsoft has it freely available: http://www.microsoft.com/typography/fonts/font.aspx?FMID=181...
Freely? If you read that page, you'll find it is $30 per typeface or $110 for a family of four, for use on workstations. Few if any people will buy that, though, as the font ships with lots of software (for example, it ships with Mac OS X and Windows)
IMO they are far from indistinguishable (maybe you are thinking about Menlo?). I find Akkurat Mono more pleasant to use. DejaVu Sans Mono looks too dense compared to Akkurat Mono's softer looks.
Since people seem to care about it, I should also note that it has a nice slashed zero you can see on line 6 which I prefer to DSM's dotted counterpart.
Edit: Here's how it looks like when I adjust DSM's line-spacing to match Akkurat Mono's default, it still has that busy look: http://cl.ly/image/1z3Z393x1s3l/o
Busy look? Akkurat Mono is simply more squat and tight; look at the "a" and "e", for example. For me, it gives a gnarly, squinting kind of look reminiscent of Courier New, compared to Deja's more rounded openness.
I really dislike Akkurat's bloated commas and semicolons, the exaggerated "+" (which has not enough spacing, either), and the shallow braces are not good, they look like parantheses.
The only thing I like about Akkurat, I have to say, is the less classical "&". Deja uses the "et"-style ampersand, which looks unfinished at the kind of code sizes used for programming.
But each to his own, I guess.
And that slashed zero is an Ø [1], my friend, not a zero. :-)
Fair points all around (though I disagree with all of them except "+" being exaggerated). DejaVu's characters are a bit too tall for my taste, a clear example of this is the oval 'o' character. I also like to have a pronounced difference in the height of lower case and upper case letters.
Since we are doing character by character comparison I find "="s of DejaVu too wide (which causes "===" to look bad). It's "<" and ">" are too tight which makes it look bad when used as angle brackets. Backticks are slimmer, lower case "L" looks out of place and (apparently) it doesn't have an italic "*" (I don't know if Akkurat Mono is supposed to have it but it looks nice).
I guess you pinpointed one reason I like Deja so much: The x height of its lowercase letters is slightly higher than the median line.
In other words, the x height is higher than the middle stroke in capital "E" (or "F", "A", etc.). The reason I like this is because code uses mostly lowercase letters (unless you write COBOL), and if you keep the x height classically aligned, the font ends up looking squat and gnarly, like Akkurat.
Deja exaggerates the x height by (in display terms, at the point size that I use) two pixels, which evens it out and "fills out" the line height more nicely, making for a more harmonic flow, even though this also means the middle strokes of some capital letters don't line up with the tops of the lowercase letters. (This is not a violation of typography rules, by the way.)
Fonts like Akkurat, with classical x heights, look more sparse because lines with only lowercase letters leave more room above the x height, and the difference in height between lower and upper case is more pronounced.
Anyway.
I agree that Deja's angle brackets are a bit too angled. Akkurat's is better.
The problem with Deja's "=" is not the length but the spacing. It has the same spacing issue as Akkurat's "+".
However, I categorically reject your criticism of Deja's lower-case "L". It's perfect because it looks precisely like the character L, whereas Akkurat's "l" looks like the number 1. (It's also consistent with the overall shape of the font, matching the arcs in characters such as f and j.)
I was jesting about the 0/Ø. I don't care whether there is a center dot or a slash myself.
Looked at Liberation, but it's not for me. Too... squished.
> The problem with Deja's "=" is not the length but the spacing. It has the same spacing issue as Akkurat's "+".
Doesn't it become a length problem when we are talking about a fixed-width font though?
Thanks for elaborating, you obviously know more about typography than I do! I don't have much reasoning behind my choice of font apart from personal taste.
I just took another look at Liberation Mono for the first time in years and it is eerily similar to Akkurat Mono which probably explains why I like both of them so much.
> Doesn't it become a length problem when we are talking about a fixed-width font though?
When drawn on its own with a space before and after, the length itself is not the problem, but of course in a monospace font, character_spacing = (character_width - actual_width_of_glyph), so you are right in that respect. Semantics. :-)
I usually disable bold fonts in my editor and terminal emulator (I like when they provide an option like "draw bold text in bright colors") but I see your point. It would definitely be nice if they were available especially considering the price tag.
I don't own a Retina display and I'm not sure about the correct scale but here is an example rendering of Akkurat Mono in a bigger font size: http://cl.ly/image/16423o3J0H3N/o
Well, I've never really quibbled over the price of a font if I liked it. I bought PragmataPro as well, a few years ago, and used it for quite some time.
Answer is, Akkurat Mono looks rather nice on Retina, going to use it for a while and see if its one of the classics like Inconsolata.
These newfangled Mac OS X users have not used it enough to appreciate it’s pixel-perfected beauty. I’ve been using it as my monospaced font of choice since 1996 when I started to use Macs.
Terminus starts looking slightly bad in bold and slanted variants and their editor looks like uses it bolded for some reason. Personally, I love Terminus and use it for my terminal and text editor with GNU Unifont as fallback for Asian scripts.
They're not. That comparison was taken from the Inconsolata-g page and is either outdated or inaccurate. Visit the Inconsolata page to see the actual font (which hasn't changed since 2009, I believe): http://levien.com/type/myfonts/inconsolata.html
The 1/l distinction isn't that bad, but the curved quotation marks and apostrophe were enough to warrant a variant, Inconsolata-dz[1]. Looks like Inconsolata-g is actually built upon the -dz variant because it includes the straight quotation marks and apostrophe.
I like serifs so I use Luxi Mono. It used to be the RedHat console font and it was inspired by the Sun console font. On Debian it's in the ttf-xfree86-nonfree package.
+1 For Luxi Mono; technically it is terrible for programming (0&O and 1&l pairs look almost the same), but I'm somehow addicted to it. So I really hope one day someone will make open source "Luxi Mono-g" clone...
If you'd like to see tiny fonts taken to the extreme, check out "The Bee’s Knees", a font with x-height of 3 pixels but surprisingly legible because it uses subpixel rendering:
I've been using Glyphs on a Mac to create web-icon fonts for the site I make, but it also seems to be able to edit fonts (most of the time). I don't really know a ton about font-making, but it seems that with most of the fonts you'd edit, the kerning and all that is already defined.
If it's a matter of adding a couple slashes to 7's/Z's or to 0's, that should be reasonably straight-forward to do. In Glyphs, it would be a matter of adding a new shape for the slash wherever you want it. Then File -> Export and you're on your way.
(And obviously you might run into license violations if you're changing fonts you're not allowed to. This post isn't meant to address the legal side of it, just a guy at his desk fixing fonts for his own use.)
The way I write the numeral '1', I'm in more danger of confusing it with lowercase 'l' than numeral '7'. I believe this is one of those little things that helps mark people out as European or American. (To prevent my numeral '1' from colliding with my lowercase 'l', I'll add tiny serifs to the numeral top and bottom.)
Confusing capital 'Z' with numeral '2' is possible for me; luckily, capital 'Z' is really uncommon in what I create. If I feel it might be a problem, I'm likely to increase the curviness of the top of my numeral '2'.
Anyway, this is all handwriting. Typefaces, which aren't scrawled in haste, have a lot of other tricks they can use to distinguish glyphs.
Its some what old school it's to stop confusing similar symbols O and 0 for example - It may be more common in the more technical branches of programming and in science and tech fields.
The instructions for the Consolas font on Mac OS include downloading an Office update for Mac and extracting the font. I just realized that I already have the font installed, since I also have a copy of Office installed :)
I used Inconsolata and thought I would never switch again. Now I am finding myself using Ubuntu Mono. It's not that Inconsolata is bad or something, I guess you will get bored anyhow after one or two years.
Offbeat suggestion (and definitely not free or readily available) - LineTo Akkurat Mono. I've always been a little bit obsessed with monospace type & this is definitely my favourite. I use it in Sublime, Vim & iTerm 2 - hate using Macs that don't have it installed. http://lineto.com/The+Fonts/Font+Categories/Text+Fonts/Akkur...
The site needs to make it clearer which font is the best, it looks initially like it's a countdown from 50 of the best fonts (the second font has 49) and then when I get to the bottom there is a ton of them on 0 so I presume now they are votes.. pretty confusing
So I browsed around for a free alternative of Nitti, most popularly known as iA Writer's font. Someone recommended an alternative: Cousine. http://www.fontsquirrel.com/fonts/cousine
moved around a fair bit between DejaVu Sans Mono/Inconsolata/Consolas etc before eventually settling on Ubuntu Mono, which really holds up extremely well at smaller sizes (7/8 pt)
I wanted to add a vote for Lucida Console, but stopped when it was asking me to login. Oh well! I like the letter shapes in some other fonts better, but Lucida Console is the only one with proper horizontal width IMHO, although it could be I've just been using it too long.
We'll definitely be iterating on how we rank and present viewpoints to try to reduce bias. We don't want to remove indicators of popularity entirely, though, since that would reduce the utility of the site for readers who are still trying to decide. We do intend, though, to at least provide enough information for users to judge where there may be bias for themselves, and we'll try to eliminate it where we can.
So to reply to my own question, a minimal standard would be the first four code blocks, plus Greek, math operators, and box drawing symbols. Anonymous Pro and Andale Mono reach this standard, Inconsolata doesn't.
A higher standard would be Menlo and Courier New, both having all those plus the Greek Extended (with accents), Cyrillic, Hebrew and Arabic sets, and a mess of other symbols. Deja Vu Sans Mono is missing the Hebrew, at least the version I have, but adds a bunch of dingbats and miscellaneous symbols. Everson Mono (not mentioned in the subject article and not a great programming font) has even more, all the odd-ball language support like Lao and Gothic.
Edit after checking the others mentioned: Only Menlo, Courier New, and Liberation Mono have Hebrew, a bit of a surprise given how much software is done in Israel. Those three have the largest complements of glyphs, and Liberation Mono is open and free.
[1] http://en.wikipedia.org/wiki/Liberation_fonts
[2] https://fedorahosted.org/liberation-fonts/
[3] http://www.donationcoder.com/Software/Jibz/Dina/