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.
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
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...
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.)
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 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.
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.
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)?
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.
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.
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.
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.
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.
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.
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.
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)
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!
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.
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.
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 :)
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.
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...
143 comments
[ 26.3 ms ] story [ 4181 ms ] thread[1]: http://nodnod.net/2009/feb/12/adding-straight-single-and-dou...
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.)
(Edit: typo.)
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.
You can try it out if you select Monospaced from the dropdown here: http://www.linuxlibertine.org/index.php?id=86&L=1
Other than that from that list of fonts, Source Code Pro looks quite good too.
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.
The only time I ran into length problems was when I was asked to print my code on A4 paper for an exam.
mixing tabs and spaces is strange and IMO should be avoided, but it sometimes happen :( all-spaces FTW
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.
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:
instead of this: 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.
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.
True, but why do it in the first place?
Note that I'm not supporting proportional fonts here -- I much prefer fixed-width -- but I also don't like formatting function signatures like that.
For me, I prefer reading and editing vertically aligned code.
Also I don't find it overly difficult to make sure everything is line up vertically.
Like most things, I think it really just boils down to an aesthetic preference, and it's usually up to whoever actually maintains the code anyway. :)
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.
[1] http://www.activestate.com/komodo-edit
[2] http://www.zeusedit.com/
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.
Do you ever work in a team?
Yes, of course, many times. And on teams with a variety of coding standards, some loose and some more strict.
Did the coding style I suggested seem unsuitable for team use?
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:
vs. That's a line width of 84 vs. 56 for the same code. Fair enough?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! :-)
1. http://nickgravgaard.com/elastictabstops/
I kindof makes sense because ObjC methods are so wordy, that you would want a font aimed at readability rather than symbols.
My Xcode theme is here gor anyone who wanta to try http://objectivesea.tumblr.com/post/3109860705/newromantimes...
* The pixel density of your display
* Rendering method (ClearType, OSX anti-aliasing, etc.)
* The size of text you prefer
* How sharp your vision is
* And of course, personal taste.
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.
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.
I could not live without column editing.
(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.)
Komodo doesn't switch automatically, but you can set up a keyboard shortcut to switch between monospaced and proportional fonts.
For example https://github.com/torvalds/linux/blob/master/security/commo...
you are writing "cap_capget", you could write three lines,
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 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. Here is some quick example of how you could use column mode during programming.http://www.youtube.com/watch?v=yeYmPV3DpG8
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 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.
What legality concerns?
Why would tens of thousands of sites from google be of interest?
And of coure microsoft has the font. It's their font afterall.
"Verdana is a humanist sans-serif typeface designed by Matthew Carter for Microsoft Corporation" [Wikipedia]
Xcode handles mixed proportional and monospaced fonts fairly well. Comments are in a monospaced font, everything else is proportional.
I assume you were joking, but the issue of ascii art in the comments actually came up super quickly when I switched to proportional fonts.
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.
Thanks for the tip!
(67% joking - as you know ascii art in comments is sometimes a real thing.)
(99% joking)
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!
Right now, votes are directly influenced by page order, which I suppose is indicative that people don't feel strongly about their fonts.
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.
I use it with Sublime Text 2 and the scheme called Big Duo
http://cl.ly/image/3M413B322I1O
http://damieng.com/blog/2008/05/26/envy-code-r-preview-7-cod...
or Source Code Pro
https://github.com/adobe/source-code-pro
On Mac, I use Source Code Pro or Menlo.
http://i.imgur.com/qNlpYvn.png
http://www.dafont.com/bitstream-vera-mono.font
http://dejavu-fonts.org/wiki/Main_Page
Here's how it looks on my system: http://ozansener.com/images/github-browse-file-1.png
Homepage: http://lineto.com/The+Fonts/Font+Categories/Text+Fonts/Akkur...
[1] http://dejavu-fonts.org/wiki/Main_Page
Here is a side by side comparison: http://cl.ly/image/1j030D031g0U/o
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
Here's an animation comparing them (Deja is the bigger one, Akkurat the squat one): http://i.imgur.com/lkOzDWN.gif
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. :-)
[1] http://en.wikipedia.org/wiki/Ø
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 don't get the point you are trying to make about slashed zeros. https://en.wikipedia.org/wiki/Slashed_zero
It all boils down to personal preference, thanks for stating yours :). You might also like Liberation Mono, which is my second favorite.
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.
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.
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. :-)
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.
http://cl.ly/image/1j1N3E0k2O10 (Objective-C)
Thanks for linking the font!
http://i.imgur.com/4NhZ3h2.png http://i.imgur.com/yaCGIWG.png
http://www.boldmonday.com/en/nitti
I love working in that typeface and have it set to default in Sublime Text and Terminal.
If you have even a mildly decent display (1920x1080 at 15.6"), pixel fonts are beautiful and readable.