5 ms·

So you're trying to dictate a coding style to make up for tabs' weaknesses? That's like Apple's reaction to bad reception on phones: "You're holding it wrong".

So you're trying to dictate a coding style to make up for tabs' weaknesses? That's like Apple's reaction to bad reception on phones: "You're holding it wrong". No, thanks, I'd rather use spaces that don't require any workarounds.

Stratoscope 10y ago
> So you're trying to dictate a coding style to make up for tabs' weaknesses? Not in the slightest. The disadvantages of column alignment have nothing to do with whether you use tabs or spaces. I don't recall for sure, but I think I was using spaces for indentation at the time that I stopped using column alignment. Column alignment has the same problems if you indent with spaces: it leads to excessive line length, it's unfriendly toward source control diffs, it's fiddly to maintain, it mandates the use of a monospaced font, and I find that it harms readability compared to the alternative of using indentation. Take a look at the Servo code examples I linked to in another comment. Are the column-aligned versions a better way to format code than the indented versions? Here's another way to look at it. 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: if( foo == bar ) { if( baz == moo ) { console.log( "yes" ); this.that = true; } else { console.log( "no" ); this.that = false; } } instead of: if( foo == bar ) { if( baz == moo ) { console.log( "yes" ); this.that = true; } else { console.log( "no" ); this.that = false; } } It is probably obvious that I prefer the latter, as would most developers. So why not apply the same formatting principle to expressions that we apply to statements?
- yAnonymous 10y ago
  "Many of us" - you are using that way too often in your posts and it's a pseudo argument. Fact is, you're giving up the choice of different coding styles to make something broken work. "Many of us" prefer spaces for that reason and that's why it has become the de facto standard.
  - Stratoscope 10y ago
    Your point about my overuse of "many of us" is a good one, so I changed it to "I" in the comment you just replied to. Fair enough? But look, my real point here is that column alignment is detrimental in several ways, and indentation is a better way to illustrate your code structure - both for statements and expressions. Using indentation instead of column alignment isn't a workaround for anything - it's just a more practical, readable, maintainable way to format your code. This question really has nothing to do with tabs or spaces.
    - yAnonymous 10y ago
      I see the points for VCS and non-monospace fonts, minor as they may be, but readability is absolutely a matter of choice. While we're on the matter of user prefereces and numbers: Most style guides recommend spaces as lined out in my other post. >Google, Microsoft, Apache and NASA for C-family languages, Crockford and almost every other web-related style guide I've ever seen recommend the use of spaces. Apple is a notable exception. That doesn't make them right, but I'd like to know how you came up with the "many of us" in the first place, because there are far more developers who use spaces (https://ukupat.github.io/tabs-or-spaces/ https://ukupat.github.io/tabs-or-spaces/), and it's not even close.
      - scrollaway 10y ago
        "Many of us" doesn't imply "a majority of us". This statement isn't contradictory and is backed up by the data you linked: "Many of us use tabs. Many of us use spaces. Some of us use form-feed.. bloody nutters!"
  - scrollaway 10y ago
    > "Many of us" prefer spaces for that reason and that's why it has become the de facto standard Has it? I wasn't informed. I know it has in the Python community, because of pep8 mainly, but a lot of communities have settled on tabs (Lua for example, and for a long time PHP until recently). I'll paste here what I replied to someone off-thread, regarding "why" anything ever becomes a de facto standard. > I would bet quite a bit that personal indent preferences are driven by whatever the default is on the editor of choice of the person in question. I would equally bet that you can correlate the tab defaults on editors/IDEs widely used in specific communities (Visual Studio for Windows C-family stacks, PyCharm for python, Eclipse and its little family for java, etc) and the general preference of that community. Chicken and egg problem. Spaces aren't standard because they're preferred; they're preferred because they're standardized by editor defaults. Developers that don't have a particular preference grow into those defaults.
- lokedhs 10y ago
  That's a good question. Lisp programmers such as myself do indeed format code like your first example all the time. In fact, having done a lot of Lisp programming recently, I wanted to format some Java code using that style too, but IDEA's code formatter is too limited to allow me to do that.
- chriswarbo 10y ago
  > 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.

Stratoscope 10y ago

> So you're trying to dictate a coding style to make up for tabs' weaknesses? Not in the slightest. The disadvantages of column alignment have nothing to do with whether you use tabs or spaces. I don't recall for sure, but I think I was using spaces for indentation at the time that I stopped using column alignment. Column alignment has the same problems if you indent with spaces: it leads to excessive line length, it's unfriendly toward source control diffs, it's fiddly to maintain, it mandates the use of a monospaced font, and I find that it harms readability compared to the alternative of using indentation. Take a look at the Servo code examples I linked to in another comment. Are the column-aligned versions a better way to format code than the indented versions? Here's another way to look at it. 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: if( foo == bar ) { if( baz == moo ) { console.log( "yes" ); this.that = true; } else { console.log( "no" ); this.that = false; } } instead of: if( foo == bar ) { if( baz == moo ) { console.log( "yes" ); this.that = true; } else { console.log( "no" ); this.that = false; } } It is probably obvious that I prefer the latter, as would most developers. So why not apply the same formatting principle to expressions that we apply to statements?

yAnonymous 10y ago
"Many of us" - you are using that way too often in your posts and it's a pseudo argument. Fact is, you're giving up the choice of different coding styles to make something broken work. "Many of us" prefer spaces for that reason and that's why it has become the de facto standard.
- Stratoscope 10y ago
  Your point about my overuse of "many of us" is a good one, so I changed it to "I" in the comment you just replied to. Fair enough? But look, my real point here is that column alignment is detrimental in several ways, and indentation is a better way to illustrate your code structure - both for statements and expressions. Using indentation instead of column alignment isn't a workaround for anything - it's just a more practical, readable, maintainable way to format your code. This question really has nothing to do with tabs or spaces.
  - yAnonymous 10y ago
    I see the points for VCS and non-monospace fonts, minor as they may be, but readability is absolutely a matter of choice. While we're on the matter of user prefereces and numbers: Most style guides recommend spaces as lined out in my other post. >Google, Microsoft, Apache and NASA for C-family languages, Crockford and almost every other web-related style guide I've ever seen recommend the use of spaces. Apple is a notable exception. That doesn't make them right, but I'd like to know how you came up with the "many of us" in the first place, because there are far more developers who use spaces (https://ukupat.github.io/tabs-or-spaces/ https://ukupat.github.io/tabs-or-spaces/), and it's not even close.
    - scrollaway 10y ago
      "Many of us" doesn't imply "a majority of us". This statement isn't contradictory and is backed up by the data you linked: "Many of us use tabs. Many of us use spaces. Some of us use form-feed.. bloody nutters!"
- scrollaway 10y ago
  > "Many of us" prefer spaces for that reason and that's why it has become the de facto standard Has it? I wasn't informed. I know it has in the Python community, because of pep8 mainly, but a lot of communities have settled on tabs (Lua for example, and for a long time PHP until recently). I'll paste here what I replied to someone off-thread, regarding "why" anything ever becomes a de facto standard. > I would bet quite a bit that personal indent preferences are driven by whatever the default is on the editor of choice of the person in question. I would equally bet that you can correlate the tab defaults on editors/IDEs widely used in specific communities (Visual Studio for Windows C-family stacks, PyCharm for python, Eclipse and its little family for java, etc) and the general preference of that community. Chicken and egg problem. Spaces aren't standard because they're preferred; they're preferred because they're standardized by editor defaults. Developers that don't have a particular preference grow into those defaults.
lokedhs 10y ago
That's a good question. Lisp programmers such as myself do indeed format code like your first example all the time. In fact, having done a lot of Lisp programming recently, I wanted to format some Java code using that style too, but IDEA's code formatter is too limited to allow me to do that.
chriswarbo 10y ago
> 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.