5 ms·

Personally, I don't find the value in alignment - indentation is all I do. I especially dislike alignment of this sort: var a_variable = 1; v

Personally, I don't find the value in alignment - indentation is all I do. I especially dislike alignment of this sort: var a_variable = 1; var another_variable = 2; var yet_another_variable = 3; which is just too fiddlesome and in fact makes it _harder_ for me to read.

zbjornson 10y ago
That's also hazardous when you later add an_even_longer_variable and then have to modify three extra lines to make them align.
- spinningarrow 10y ago
  Exactly. To be fair, I believe most popular editors have plugins/shortcuts to do this. Or at least I hope people aren't doing this manually.
  - dkuntz2 10y ago
    But if anyone looks at a diff, it looks like all the lines have changed, instead of just one, taking just a tiny bit more cognitive overhead.
    - citrusx 10y ago
      `git diff -w`
      - tnorthcutt 10y ago
        But `git blame` still sees the whitespace change, right? Edit: turns out `git blame -w` works as expected, ignoring whitespace. The More You Know™
jasonpeacock 10y ago
That's what code formatting tools (cncrustify, clang-format, etc) were built to fix - let the computer have perfect and consistent formatting, you just need to record your intention.
dozzie 10y ago
There's different kind of alignment, the one you get from breaking too long line. // some code // ... var some_call_result = some_object.a_method(with, quite_long, list_of, parameters) In the second line you get indent (up to `var' keyword level), and then alignment. The former would be fine with tabs, but the latter must be spaces. Unfortunately there's no editor that deals with tabs in this situation correctly, which means spaces is the only way to go.
- spinningarrow 10y ago
  While I see what you're getting at, I actually prefer indentation in this case as well. Something like: var some_call_result = some_object.a_method( with, quite_long, list_of, parameters ) Alignment adds inconsistent negative space to the code which I find breaks the flow and makes it hard to read because lines start at arbitrary columns. If your method name grows or shrinks, the alignment in your example needs to be fixed whereas with simple indentation there's no such need.
  - dozzie 10y ago
    What you presented indeed has no alignment spaces, so all-tabs approach works. The thing is, there are codebases that use "my" line breaking, and with no editor that handles that case correctly, tabs are just no-go. > If your method name grows or shrinks, the alignment in your example needs to be fixed whereas with simple indentation there's no such need. I gladly accept this drawback, for the sake of situations when a linebreak is necessary, but the argument list is just too short to be split it into separate lines like in your example. (The necessity is a matter of taste, obviously.) I admit, these situations are rare, but they happen from time to time, so I simply don't use tabs.

zbjornson 10y ago

That's also hazardous when you later add an_even_longer_variable and then have to modify three extra lines to make them align.

spinningarrow 10y ago
Exactly. To be fair, I believe most popular editors have plugins/shortcuts to do this. Or at least I hope people aren't doing this manually.
- dkuntz2 10y ago
  But if anyone looks at a diff, it looks like all the lines have changed, instead of just one, taking just a tiny bit more cognitive overhead.
  - citrusx 10y ago
    `git diff -w`
    - tnorthcutt 10y ago
      But `git blame` still sees the whitespace change, right? Edit: turns out `git blame -w` works as expected, ignoring whitespace. The More You Know™

jasonpeacock 10y ago

That's what code formatting tools (cncrustify, clang-format, etc) were built to fix - let the computer have perfect and consistent formatting, you just need to record your intention.

dozzie 10y ago

There's different kind of alignment, the one you get from breaking too long line. // some code // ... var some_call_result = some_object.a_method(with, quite_long, list_of, parameters) In the second line you get indent (up to `var' keyword level), and then alignment. The former would be fine with tabs, but the latter must be spaces. Unfortunately there's no editor that deals with tabs in this situation correctly, which means spaces is the only way to go.

spinningarrow 10y ago
While I see what you're getting at, I actually prefer indentation in this case as well. Something like: var some_call_result = some_object.a_method( with, quite_long, list_of, parameters ) Alignment adds inconsistent negative space to the code which I find breaks the flow and makes it hard to read because lines start at arbitrary columns. If your method name grows or shrinks, the alignment in your example needs to be fixed whereas with simple indentation there's no such need.
- dozzie 10y ago
  What you presented indeed has no alignment spaces, so all-tabs approach works. The thing is, there are codebases that use "my" line breaking, and with no editor that handles that case correctly, tabs are just no-go. > If your method name grows or shrinks, the alignment in your example needs to be fixed whereas with simple indentation there's no such need. I gladly accept this drawback, for the sake of situations when a linebreak is necessary, but the argument list is just too short to be split it into separate lines like in your example. (The necessity is a matter of taste, obviously.) I admit, these situations are rare, but they happen from time to time, so I simply don't use tabs.