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

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.

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.

`git diff -w`

But `git blame` still sees the whitespace change, right?

Edit: turns out `git blame -w` works as expected, ignoring whitespace. The More You Know™

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.

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.

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.

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.