5 ms·

In most languages there's not really much need to display source code in monospace, except to the extent that a previous programmer formatted code with that ass

by waqf 11y ago

In most languages there's not really much need to display source code in monospace, except to the extent that a previous programmer formatted code with that assumption. When you're trying to align lines of a block, you only need that a string of n initial spaces (or tabs) is the same width every time: you don't care if it is the same as a string of n arbitrary characters. This suffices for the compiler-enforced indentation rule in Python (though not, I think, for the indentation rule in Haskell). (I code in a variable-width font in Emacs and I work on shared codebases. The codebase style does have a couple alignment rules that don't make sense for variable-width fonts, but I just let Emacs enforce them and I'm happy that overall the code as I see it is easier on the eyes than it would be with fixed-width formatting.)

gchpaco 11y ago
Acme, too, defaults to variable width, and looks rather better for it. It's always a little awkward in Emacs because a lot of the system packaging (package.el, for example) assumes mono, but it can work.
scythe 11y ago
How do you deal with the fact that in most variable-width fonts, the characters []{}():;'!.*,|`ijl are often too small/narrow to really notice? I've looked into programming with variable-width fonts, but I kept finding that monospace fonts are much easier on the eyes. It's hard to even look at typical C code in a variable-width font.
- waqf 11y ago
  I don't have a perfect solution, but using syntax highlighting together with a bold font weight goes a long way to make typos apparent.
douche 11y ago
There are a few simple rules I have for code fonts: 1.) Monospace - I don't really go nuts about aligning things, but it is nice for looking at multi-line strings in code. 2.) Characters need to be distinct. l (lower-case ell), i (lower-case eye), I (upper-case eye) and 1 (one) cannot appear identical. 0, o and O shouldn't be the same - bonus if zero has a dot or line through the center. Visual Studio defaults to Consolas, which is nice.
akkartik 11y ago
Now that I think about it, the biggest reason I continue using fixed-width is that my preferred 2-space indent looks narrower and so indentation becomes less salient. Perhaps I should just increase my indent. 2 spaces is mandated at work, though, so there's that..
- seanmcdirmid 11y ago
  Try using indent guidelines if they are available on your IDE (built in or as a plug in). I work with two space indent, minified curly braces, proportional font, and indent guidelines...it is quite nice and feels "modern."
blahedo 11y ago
The other main case where monospace (as such) is important is when multi-line expressions should be lined up in some semantically relevant way, e.g. to reflect boolean and/or grouping, or to line up function arguments. (This is especially true in Lisp/Scheme indent styles, but I use it fairly frequently in the C-style-syntax languages as well.) Separately from the "lining things up" argument, though, there's an argument to be made for characters in any editing situation to be wider, even if they're not all the same width. For naturally-narrow letters like I and l, and for periods and commas, and of course spaces, the non-monospace fonts often make them so narrow that they become harder to target with a mouse, harder to distinguish from each other, and in some cases hard to even see at a glance whether the insertion point is to their left or right. This is a UI problem with a lot of editors (e.g. text entry for data or comments on the web) that doesn't get enough attention; if the content and presentation can be separate (i.e. it's not a WYSI-more-or-less-WYG editor) then the editor should use a font that doesn't have super-narrow anything. Monospace is a convenient way to achieve that.
- Stratoscope 11y ago
  You don't need a monospaced font to line up multiline expressions or function arguments. All you have to do is use indentation instead of column alignment. In other words, follow the same rules for expressions that you most likely already use for statements. For example, instead of this: someObject.someMethod(oneArgument, anotherArgument, oneMoreArgumentForTheRoad); Format it exactly as you would if the parentheses were curly braces: someObject.someMethod( oneArgument, anotherArgument, oneMoreArgumentForTheRoad ); Or instead of this: string someVariable = oneThing + anotherThing + yetAnotherThing; Do this: string someVariable = oneThing + anotherThing + yetAnotherThing; The code is just as readable this way, and you gain many benefits: * Your code looks exactly the same in a proportional or monospaced font, so people viewing the code are free to choose either. * You no longer need to fiddle with adding or removing spaces when you change the length of one of your variables or function names. * The diffs in your revision history no longer show spurious changes that result from that column fiddling. * Your code lines become much shorter. * Instead of having one formatting rule for curly braces and a completely different rule for parentheses, you use the same formatting rule for everything. * It doesn't matter if the code is indented with spaces or tabs. With no column alignment, rules like "tabs for indentation, spaces for alignment" are no longer needed. * If you need to change the code to a new indentation style (e.g. change 2 or 4 spaces to tabs, or vice versa), you can do that reliably with a simple regex search and replace, with no damage to the code formatting and no manual cleanup required. I adopted this practice long before I switched to coding in proportional fonts - and once I started formatting code this way I realized that it didn't matter any more what kind of font I used. I was free to choose any font that pleased my eyes, with no impact on the readability of the code for those who prefer monospaced fonts. A good place to see the problems that column alignment causes is the Servo source code, whose coding standard mandates column alignment. I posted a few examples here: https://news.ycombinator.com/item?id=9469713 https://news.ycombinator.com/item?id=9469713 I've often wondered why column alignment is so popular given its drawbacks. I have a theory that I think explains some of it, at least in the case of function calls and parenthesized expressions. It's because of the very common objection to putting spaces inside the parentheses. For example, PEP8 and many coding standards explicitly forbid this. Here's what happens. Take my first example above, written as one line without spaces inside the parentheses: someObject.someMethod(oneArgument, anotherArgument, oneMoreArgumentForTheRoad); That line is too long, so let's fix it. The natural starting place is to change every space to a newline: someObject.someMethod(oneArgument, anotherArgument, oneMoreArgumentForTheRoad); That's a bit messed up, so what can we do? Indent the extra lines? someObject.someMethod(oneArgument, anotherArgument, oneMoreArgumentForTheRoad); Ugh. Now the arguments don't line up at all. It's really ugly. The only cure is to align the columns: someObject.someMethod(oneArgument, anotherArgument, oneMoreArgumentForTheRoad); But what if we adopted the practice of putting spaces inside the parentheses? someObject.someMethod( oneArgument, anotherArgument, oneMoreArgumentForTheRoad ); If we make the same substitution, changing each space to a newline, we get this: someObject.someMethod( oneArgument, anotherArgument, oneMoreArgumentForTheRoad ); And now it makes perfect sense to indent the arguments: someObject.someMethod( oneArgument, anotherArgument, oneMoreArgumentForTheRoad ); This is the same thing we intuitively do with curly braces. After all, hardly anybody codes like this: while(true) {oneStatement; anotherStatement; oneMoreStatement;} I think one reason is that we pretty much tend to put spaces inside the curly braces, even in a one-liner. It's not too common to write this: while(true) {oneStatement; anotherStatement; oneMoreStatement;} Instead, this seems more typical (if you use a one-liner at all, which I'm not arguing for or against): while(true) { oneStatement; anotherStatement; oneMoreStatement; } No one seems to mind spaces inside the braces, but I've had developers totally freak out over the idea of putting spaces inside the parentheses. It Simply Is Not Done. I don't understand why there's such an objection to that, especially when it seems to lead directly to the difficulties of column alignment. I tend to think that it's because spaces never go inside the parentheses in English text. But this is code, not English, and we are free to choose conventions that benefit us, even if they differ from how we'd write prose. Edit: I added a number of thoughts after first posting this. If you upvoted this an earlier version of this comment and now think I'm insane for advocating spaces inside the parentheses, let me know and I'll post another comment that you can downvote. ;-)
userbinator 11y ago
I often use ASCII art in comments to add explanatory detail. That would become nearly impossible to do correctly with a proportional font. Another thing is easily formatting tabular-looking data (e.g. array initialisers) reasonably well. Proportional fonts mean this can't be done, and existing formatted data looks like a mess. Moving the cursor vertically with a proportional font also causes it to distractingly jump left and right instead of in a straight line. Has anyone who prefers proportional fonts considered whether they'd like proportional vertical spacing (i.e. the height of each line varies depending on what characters are in it)? That would be the other extreme of variable spacing.
- nitrogen 11y ago
  If one were completely sold on the idea of proportional fonts for coding, it would make sense to go to fixed tabstops (like a word processor or typewriter) rather than fixed-width tab characters, so tabs could always be used to align tabular data.
- ygra 11y ago
  You could have comments in monospace and the rest of the code proportional. As long as you don't start ASCII art in normal code ...

by waqf 11y ago

gchpaco 11y ago

Acme, too, defaults to variable width, and looks rather better for it. It's always a little awkward in Emacs because a lot of the system packaging (package.el, for example) assumes mono, but it can work.

scythe 11y ago

How do you deal with the fact that in most variable-width fonts, the characters []{}():;'!.*,|`ijl are often too small/narrow to really notice? I've looked into programming with variable-width fonts, but I kept finding that monospace fonts are much easier on the eyes. It's hard to even look at typical C code in a variable-width font.

waqf 11y ago
I don't have a perfect solution, but using syntax highlighting together with a bold font weight goes a long way to make typos apparent.

douche 11y ago

There are a few simple rules I have for code fonts: 1.) Monospace - I don't really go nuts about aligning things, but it is nice for looking at multi-line strings in code. 2.) Characters need to be distinct. l (lower-case ell), i (lower-case eye), I (upper-case eye) and 1 (one) cannot appear identical. 0, o and O shouldn't be the same - bonus if zero has a dot or line through the center. Visual Studio defaults to Consolas, which is nice.

akkartik 11y ago

Now that I think about it, the biggest reason I continue using fixed-width is that my preferred 2-space indent looks narrower and so indentation becomes less salient. Perhaps I should just increase my indent. 2 spaces is mandated at work, though, so there's that..

seanmcdirmid 11y ago
Try using indent guidelines if they are available on your IDE (built in or as a plug in). I work with two space indent, minified curly braces, proportional font, and indent guidelines...it is quite nice and feels "modern."

blahedo 11y ago

The other main case where monospace (as such) is important is when multi-line expressions should be lined up in some semantically relevant way, e.g. to reflect boolean and/or grouping, or to line up function arguments. (This is especially true in Lisp/Scheme indent styles, but I use it fairly frequently in the C-style-syntax languages as well.) Separately from the "lining things up" argument, though, there's an argument to be made for characters in any editing situation to be wider, even if they're not all the same width. For naturally-narrow letters like I and l, and for periods and commas, and of course spaces, the non-monospace fonts often make them so narrow that they become harder to target with a mouse, harder to distinguish from each other, and in some cases hard to even see at a glance whether the insertion point is to their left or right. This is a UI problem with a lot of editors (e.g. text entry for data or comments on the web) that doesn't get enough attention; if the content and presentation can be separate (i.e. it's not a WYSI-more-or-less-WYG editor) then the editor should use a font that doesn't have super-narrow anything. Monospace is a convenient way to achieve that.

Stratoscope 11y ago
You don't need a monospaced font to line up multiline expressions or function arguments. All you have to do is use indentation instead of column alignment. In other words, follow the same rules for expressions that you most likely already use for statements. For example, instead of this: someObject.someMethod(oneArgument, anotherArgument, oneMoreArgumentForTheRoad); Format it exactly as you would if the parentheses were curly braces: someObject.someMethod( oneArgument, anotherArgument, oneMoreArgumentForTheRoad ); Or instead of this: string someVariable = oneThing + anotherThing + yetAnotherThing; Do this: string someVariable = oneThing + anotherThing + yetAnotherThing; The code is just as readable this way, and you gain many benefits: * Your code looks exactly the same in a proportional or monospaced font, so people viewing the code are free to choose either. * You no longer need to fiddle with adding or removing spaces when you change the length of one of your variables or function names. * The diffs in your revision history no longer show spurious changes that result from that column fiddling. * Your code lines become much shorter. * Instead of having one formatting rule for curly braces and a completely different rule for parentheses, you use the same formatting rule for everything. * It doesn't matter if the code is indented with spaces or tabs. With no column alignment, rules like "tabs for indentation, spaces for alignment" are no longer needed. * If you need to change the code to a new indentation style (e.g. change 2 or 4 spaces to tabs, or vice versa), you can do that reliably with a simple regex search and replace, with no damage to the code formatting and no manual cleanup required. I adopted this practice long before I switched to coding in proportional fonts - and once I started formatting code this way I realized that it didn't matter any more what kind of font I used. I was free to choose any font that pleased my eyes, with no impact on the readability of the code for those who prefer monospaced fonts. A good place to see the problems that column alignment causes is the Servo source code, whose coding standard mandates column alignment. I posted a few examples here: https://news.ycombinator.com/item?id=9469713 https://news.ycombinator.com/item?id=9469713 I've often wondered why column alignment is so popular given its drawbacks. I have a theory that I think explains some of it, at least in the case of function calls and parenthesized expressions. It's because of the very common objection to putting spaces inside the parentheses. For example, PEP8 and many coding standards explicitly forbid this. Here's what happens. Take my first example above, written as one line without spaces inside the parentheses: someObject.someMethod(oneArgument, anotherArgument, oneMoreArgumentForTheRoad); That line is too long, so let's fix it. The natural starting place is to change every space to a newline: someObject.someMethod(oneArgument, anotherArgument, oneMoreArgumentForTheRoad); That's a bit messed up, so what can we do? Indent the extra lines? someObject.someMethod(oneArgument, anotherArgument, oneMoreArgumentForTheRoad); Ugh. Now the arguments don't line up at all. It's really ugly. The only cure is to align the columns: someObject.someMethod(oneArgument, anotherArgument, oneMoreArgumentForTheRoad); But what if we adopted the practice of putting spaces inside the parentheses? someObject.someMethod( oneArgument, anotherArgument, oneMoreArgumentForTheRoad ); If we make the same substitution, changing each space to a newline, we get this: someObject.someMethod( oneArgument, anotherArgument, oneMoreArgumentForTheRoad ); And now it makes perfect sense to indent the arguments: someObject.someMethod( oneArgument, anotherArgument, oneMoreArgumentForTheRoad ); This is the same thing we intuitively do with curly braces. After all, hardly anybody codes like this: while(true) {oneStatement; anotherStatement; oneMoreStatement;} I think one reason is that we pretty much tend to put spaces inside the curly braces, even in a one-liner. It's not too common to write this: while(true) {oneStatement; anotherStatement; oneMoreStatement;} Instead, this seems more typical (if you use a one-liner at all, which I'm not arguing for or against): while(true) { oneStatement; anotherStatement; oneMoreStatement; } No one seems to mind spaces inside the braces, but I've had developers totally freak out over the idea of putting spaces inside the parentheses. It Simply Is Not Done. I don't understand why there's such an objection to that, especially when it seems to lead directly to the difficulties of column alignment. I tend to think that it's because spaces never go inside the parentheses in English text. But this is code, not English, and we are free to choose conventions that benefit us, even if they differ from how we'd write prose. Edit: I added a number of thoughts after first posting this. If you upvoted this an earlier version of this comment and now think I'm insane for advocating spaces inside the parentheses, let me know and I'll post another comment that you can downvote. ;-)

userbinator 11y ago

I often use ASCII art in comments to add explanatory detail. That would become nearly impossible to do correctly with a proportional font. Another thing is easily formatting tabular-looking data (e.g. array initialisers) reasonably well. Proportional fonts mean this can't be done, and existing formatted data looks like a mess. Moving the cursor vertically with a proportional font also causes it to distractingly jump left and right instead of in a straight line. Has anyone who prefers proportional fonts considered whether they'd like proportional vertical spacing (i.e. the height of each line varies depending on what characters are in it)? That would be the other extreme of variable spacing.

nitrogen 11y ago
If one were completely sold on the idea of proportional fonts for coding, it would make sense to go to fixed tabstops (like a word processor or typewriter) rather than fixed-width tab characters, so tabs could always be used to align tabular data.
ygra 11y ago
You could have comments in monospace and the rest of the code proportional. As long as you don't start ASCII art in normal code ...