6 ms·

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

by 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. ;-)
- djent 11y ago
  I believe what the comment you're replying to is implying multiple instances of indentation on the same line. Such as: if ( $test[0] ) func1() elseif ( $test[1] ) func2() elseif ( $test[2] ) func3()
  - Stratoscope 11y ago
    That's a good point. Well, it was just an excuse for me to go off on a tangent! :-) For the example you posted, I would classify that as column alignment rather than indentation. Just to clarify my terminology, what I call indentation is something that happens at the beginning of a line only. Any additional spacing after the first nonblank character is column alignment. So the spaces before the if and elseif are indentation, and the extra spaces within the lines are column alignment (in my nomenclature). The column alignment in your example is pretty appealing, but it does have some of the same problems as other forms of column alignment. When we get to ten or eleven tests, things have to get juggled around again. Do you do this: if ( $test[0] ) func1() elseif ( $test[1] ) func2() ... elseif ( $test[10] ) func3() or this? if ( $test[0] ) func1() elseif ( $test[1] ) func2() ... elseif ( $test[10] ) func3() or go all-out with something like this? if ( $test[ 0] ) func1() elseif ( $test[ 1] ) func2() ... elseif ( $test[10] ) func3() I think basically I am just lazy and found all of this alignment so tedious that I looked for ways to avoid it. :-)
  - Symbiote 11y ago
    Elastic tabstops would solve this: http://nickgravgaard.com/elastic-tabstops/ http://nickgravgaard.com/elastic-tabstops/
- jhallenworld 11y ago
  This is pretty nice! I've been doing the same for Verilog module declarations (which can easily have 100 arguments): module fred( a, b, c ); ... endmodule I've not tried it for function calls, but it's not a bad idea... How does it look for the case of an indented block after a while or a for? Let's see: while ( a && b && c ) { a = a + 1; b = b - 1; } Hmm, maybe better than what I do now... while (a && b && c) { a = a + 1; b = b - 1; }
deleted 11y ago
[deleted]
azernik 11y ago
> 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. Have a look at Input [1]: a TrueType font built for coding, with somewhat-wide I and l and super-wide punctuation marks. The issue is one of picking the right font, not of monospace vs. not - street signs, for example, have long used different fonts from printed pages, since they demand high accuracy and fast recognition of short chunks of text at long distances, as opposed to the pleasant long-reading experience demanded from most body fonts. Most systems just happen to have built-in variable-width fonts that are terrible for coding. [1] [http://input.fontbureau.com http://input.fontbureau.com]
- pauljmartinez 11y ago
  I just started using Input, giving Anonymous Pro a little hiatus. It has been pleasant on the eyes.

by blahedo 11y ago

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. ;-)

djent 11y ago
I believe what the comment you're replying to is implying multiple instances of indentation on the same line. Such as: if ( $test[0] ) func1() elseif ( $test[1] ) func2() elseif ( $test[2] ) func3()
- Stratoscope 11y ago
  That's a good point. Well, it was just an excuse for me to go off on a tangent! :-) For the example you posted, I would classify that as column alignment rather than indentation. Just to clarify my terminology, what I call indentation is something that happens at the beginning of a line only. Any additional spacing after the first nonblank character is column alignment. So the spaces before the if and elseif are indentation, and the extra spaces within the lines are column alignment (in my nomenclature). The column alignment in your example is pretty appealing, but it does have some of the same problems as other forms of column alignment. When we get to ten or eleven tests, things have to get juggled around again. Do you do this: if ( $test[0] ) func1() elseif ( $test[1] ) func2() ... elseif ( $test[10] ) func3() or this? if ( $test[0] ) func1() elseif ( $test[1] ) func2() ... elseif ( $test[10] ) func3() or go all-out with something like this? if ( $test[ 0] ) func1() elseif ( $test[ 1] ) func2() ... elseif ( $test[10] ) func3() I think basically I am just lazy and found all of this alignment so tedious that I looked for ways to avoid it. :-)
- Symbiote 11y ago
  Elastic tabstops would solve this: http://nickgravgaard.com/elastic-tabstops/ http://nickgravgaard.com/elastic-tabstops/
jhallenworld 11y ago
This is pretty nice! I've been doing the same for Verilog module declarations (which can easily have 100 arguments): module fred( a, b, c ); ... endmodule I've not tried it for function calls, but it's not a bad idea... How does it look for the case of an indented block after a while or a for? Let's see: while ( a && b && c ) { a = a + 1; b = b - 1; } Hmm, maybe better than what I do now... while (a && b && c) { a = a + 1; b = b - 1; }

deleted 11y ago

[deleted]

azernik 11y ago

> 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. Have a look at Input [1]: a TrueType font built for coding, with somewhat-wide I and l and super-wide punctuation marks. The issue is one of picking the right font, not of monospace vs. not - street signs, for example, have long used different fonts from printed pages, since they demand high accuracy and fast recognition of short chunks of text at long distances, as opposed to the pleasant long-reading experience demanded from most body fonts. Most systems just happen to have built-in variable-width fonts that are terrible for coding. [1] [http://input.fontbureau.com http://input.fontbureau.com]

pauljmartinez 11y ago
I just started using Input, giving Anonymous Pro a little hiatus. It has been pleasant on the eyes.