I program in Python, C, C++ and Java. In all these languages I prefer a proportional font. However I had to stop, mainly because the editors I want to use (Sublime text 2 at the moment) don't support proportional fonts.
"font_face": "Verdana"
Though I may be missing something.The only mitigating factor would be that the spaces at the left margin all (presumably) have the same width.
Recent example: http://www.michielovertoom.com/pictures/kwrite-textanalyse.p...
I really enjoy reading text in proportional fonts much more than monospaced. That's true for program code as much as any other text.
Like you, it doesn't bother me to lose vertical alignment. The only vertical alignment that matters to me in code is the indentation, and that works fine in proportional fonts. (The one exception being that the popular two-space indents are really lousy in a proportional font. So I prefer tabs, or if spaces are a requirement, four-space indents.)
In fact, some time before I started using proportional fonts, I'd already changed my coding style to avoid vertical alignment other than the left margin. I used to write code something like this:
function someFunction(aParam, // This is the the main thing
anotherParam, // This is another thing
aParamWithALongerName) { // Remind me what this is for
firstStep(); // Here is a description
secondStep(); // of these three statements
thirdStepSortOf(); // that go together
}
That kind of code is the very reason for coding in monospaced fonts, but why? It is a pain to maintain and keep the spacing right, and in this (fairly realistic) example I find it extremely unhelpful to have all that whitespace separating "aParam" with its comment.Instead, about ten years ago, I switched to a style more like this:
function someFunction(
aParam, // This is the the main thing
anotherParam, // This is another thing
aParamWithALongerName // Remind me what this is for
) {
// Here is a description of these three
// statements that go together
firstStep();
secondStep();
thirdStepSortOf();
}
Now it may not be as "pretty" to have those comments on the parameters not all lined up as they were before, but it's a heck of a lot easier to maintain, and to my eyes it's easier to read too. The comments about the parameters are not related to each other, they are related to the parameter that each one applies to. With this style I can read: aParam, // This is the the main thing
as pretty much a single unit, where the excessive whitespace in my previous style made it hard to match up each parameter with its comment.Having made this change, some time later I discovered that the version of Visual Studio I was using at the time supported proportional fonts, gave it a whirl, and like you, found I really liked it.
It is true that when I read other people's code who've used columnar alignment, the alignment doesn't work any more. But for the most part that just doesn't bother me. In the few cases where the alignment really makes a difference, I just switch to a monospaced font to read that file.
My favorite editor, Komodo IDE (or the free Komodo Edit), does a marvelous job of handling this. Like many editors, you can set up a customized theme of fonts and colors, but unlike any other editor I know of, each theme includes separate selections for a proportional font and a monospaced font. For some reason they don't provide a keyboard shortcut by default to switch between them, but I mapped Alt+O (on Windows) which is unused otherwise. I remember it by thinking "prOpOrtiOnal" and "mOnOspaced". :-) So I can switch between my favorite proportional and monospaced fonts easily, and it also remembers that setting for each file I've edited.
UltraEdit and UEStudio (Windows only) are not bad here either. They don't have an explicit way to select proportional vs. monospaced, but if you press Alt+C to go into column selection mode it switches to a monospaced font while in that mode. So that's a way to view a monospaced file. I wish more editors had this kind of flexibility.
Aligning crap like that is one of the indicators I use to tell if someone is an inexperienced coder. After you write enough LOC, you eventually realize that lining things up is a waste of time. You're inevitably going to insert a line long enough to screw up your alignment, and now you'll have to bungle your diff.
One is names_with_underscores. In a monospaced font, the underscore is the same width as every other character. In a proportional font, the underscore is one of the widest of characters, and much wider than a space.
For example, in the font I'm coding in right now, an underscore is 13 pixels wide, a parenthesis is 8 pixels, and a space is only 5 pixels!
So what happens is that the underscore in a way gives more visual separation in an expression than spaces or other punctuation.
var foo_bar = some_function(one_param, another_param);
To some degree, my eyes group that code this way:var foo bar = some function(one param, another param);
My solution for this is simple: don't use names_with_underscores (except when language conventions require it, such as in Ruby), and do add spaces inside the parentheses:
var fooBar = someFunction( oneParam, anotherParam );
Why do the spaces go inside the parentheses and not outside? Well, you need a space in there somewhere, and this just doesn't work for me: var fooBar = someFunction (oneParam, anotherParam);
Nor this (with no space at all): var fooBar = someFunction(oneParam, anotherParam);
To me, the space belongs at the same place where I might put a line break if I had a too-long line. I would never break lines like this: var fooBar = someFunction
(oneParam,
anotherParam);
or like this: var fooBar = someFunction(oneParam,
anotherParam);
But I do break lines like this: var fooBar = someFunction(
oneParam,
anotherParam
);
This way the spacing goes in the same place regardless of whether it's a space or a linebreak.