5 ms·

> If the column-aligned way of writing a multiline function call or expression is such a good thing, why don't we also format blocks of statements this way: I

> If the column-aligned way of writing a multiline function call or expression is such a good thing, why don't we also format blocks of statements this way: I don't see any reason not to. Your example is pretty ugly though, as it's not particularly aligned. What about: if( foo == bar ) { if( baz == moo ) { console.log( "yes" ); this.that = true ; } else { console.log( "no" ); this.that = false; } }

scrollaway 10y ago
Why are you doing character-based right-alignment in a LTR script? It breaks with proportional fonts, and... well, if we wanted to right-align things in code, our non-document editor would probably support it by now, don't you think?
- chriswarbo 10y ago
  > Why are you doing character-based right-alignment in a LTR script? It's not right-aligned, I've aligned the "." method accessors, ";" statement delimeters, etc. into the same column, and treated "else {" as a single token. It would be even nicer to align the two pairs of statements more directly, but that ends up overflowing 80 characters, e.g. if( foo == bar ) { if( baz == moo ) { console.log( "yes" ); this.that = true ; } else { console.log( "no" ); this.that = false; } } > It breaks with proportional fonts Proportional fonts break many "in-band" layout schemes; e.g. ASCII-art layout used in plaintext email. I think "out of band" layout schemes, like CSS, would be overkill for code layout; and certainly more effort to implement than making the editor manipulate ASTs instead of character streams.
Stratoscope 10y ago
Now that is an interesting approach! So you're lining up the dots? I like the creative thinking, even if I don't like the end result. A couple of problems I see here: What happens if you have more than one dot, like foo.bar.method()? Which dots do you line up? And note that the else isn't aligned with its matching if. I suppose another alternative would be to line things up like this: if( foo == bar ) { if( baz == moo ) { console.log( "yes" ); this.that = true; } else { console.log( "no" ); this.that = false; } } Now the if and else line up, and so do the statements in the dependent blocks. But with either of these aligned formats, I'm finding it pretty hard to visualize which if statement goes with which block of statements. To me, this is one of the fundamental problems with column alignment: once you start doing it, it's too easy to start fiddling with all of the possible things you might align. And it really doesn't help the reader visualize the code structure except in the simplest cases. Also, you're in for a maintenance headache when someone changes foo to moreMeaningfulName. Now what? Move everything farther to the right? With an indentation-only format, you can change any of the variable/function names without breaking the formatting at all.
- chriswarbo 10y ago
  > To me, this is one of the fundamental problems with column alignment: once you start doing it, it's too easy to start fiddling with all of the possible things you might align. And it really doesn't help the reader visualize the code structure except in the simplest cases. I certainly agree that it can cause problems, e.g. with diffs, extraneous decisions, etc. I only tend to do it when there's commonality between the lines (more than trivial ones, like "there's a dot"); e.g. aligning the "=" in a bunch of assignments, aligning the arguments in calls to the same function, etc. > Also, you're in for a maintenance headache when someone changes foo to moreMeaningfulName. Now what? Move everything farther to the right? I tend to follow the following process: - Preserve the existing alignment (e.g. "move everything over") - If any lines grow longer than 80 characters, split them - If any already-split lines shrink to less than 80 characters, remove the split - If you spot a nicer pattern, try it - If there's no pattern anymore, "fall back" to not doing any alignment; consider inserting blank lines if the statements are very different or the lines are very dense I've thought a few times about making an auto-layout script, which would run files through a language-agnostic "nicely aligned" fitness function, and make a bunch of language-specific semantics-preserving edits to try and maximise this score. It's quite low on my TODO list though ;)

scrollaway 10y ago

Why are you doing character-based right-alignment in a LTR script? It breaks with proportional fonts, and... well, if we wanted to right-align things in code, our non-document editor would probably support it by now, don't you think?

chriswarbo 10y ago
> Why are you doing character-based right-alignment in a LTR script? It's not right-aligned, I've aligned the "." method accessors, ";" statement delimeters, etc. into the same column, and treated "else {" as a single token. It would be even nicer to align the two pairs of statements more directly, but that ends up overflowing 80 characters, e.g. if( foo == bar ) { if( baz == moo ) { console.log( "yes" ); this.that = true ; } else { console.log( "no" ); this.that = false; } } > It breaks with proportional fonts Proportional fonts break many "in-band" layout schemes; e.g. ASCII-art layout used in plaintext email. I think "out of band" layout schemes, like CSS, would be overkill for code layout; and certainly more effort to implement than making the editor manipulate ASTs instead of character streams.

Stratoscope 10y ago

Now that is an interesting approach! So you're lining up the dots? I like the creative thinking, even if I don't like the end result. A couple of problems I see here: What happens if you have more than one dot, like foo.bar.method()? Which dots do you line up? And note that the else isn't aligned with its matching if. I suppose another alternative would be to line things up like this: if( foo == bar ) { if( baz == moo ) { console.log( "yes" ); this.that = true; } else { console.log( "no" ); this.that = false; } } Now the if and else line up, and so do the statements in the dependent blocks. But with either of these aligned formats, I'm finding it pretty hard to visualize which if statement goes with which block of statements. To me, this is one of the fundamental problems with column alignment: once you start doing it, it's too easy to start fiddling with all of the possible things you might align. And it really doesn't help the reader visualize the code structure except in the simplest cases. Also, you're in for a maintenance headache when someone changes foo to moreMeaningfulName. Now what? Move everything farther to the right? With an indentation-only format, you can change any of the variable/function names without breaking the formatting at all.

chriswarbo 10y ago
> To me, this is one of the fundamental problems with column alignment: once you start doing it, it's too easy to start fiddling with all of the possible things you might align. And it really doesn't help the reader visualize the code structure except in the simplest cases. I certainly agree that it can cause problems, e.g. with diffs, extraneous decisions, etc. I only tend to do it when there's commonality between the lines (more than trivial ones, like "there's a dot"); e.g. aligning the "=" in a bunch of assignments, aligning the arguments in calls to the same function, etc. > Also, you're in for a maintenance headache when someone changes foo to moreMeaningfulName. Now what? Move everything farther to the right? I tend to follow the following process: - Preserve the existing alignment (e.g. "move everything over") - If any lines grow longer than 80 characters, split them - If any already-split lines shrink to less than 80 characters, remove the split - If you spot a nicer pattern, try it - If there's no pattern anymore, "fall back" to not doing any alignment; consider inserting blank lines if the statements are very different or the lines are very dense I've thought a few times about making an auto-layout script, which would run files through a language-agnostic "nicely aligned" fitness function, and make a bunch of language-specific semantics-preserving edits to try and maximise this score. It's quite low on my TODO list though ;)