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.

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.

I came to this conclusion too after at least 20 years of using tabs; but mostly it was because of moving to white-space significant languages like Haskell, F#, etc. It was just too painful getting everything lined up with tabs and I needed the fidelity of spaces.

Previous to that with C/C++/C# the alignment usually took care of itself through the closing brace and IDE auto-formatting. So tabs was the natural unit of currency there.

Horses for courses I guess.

Unless you're using golang,in which case gofmt will correct you. Hence the overwhelming consensus of the go row for tabs.

Go's adoption rate would be quadrupled if they had chosen spaces instead of tabs. It's a fact.

Fact? My team is using Atom, VS code, IntelliJ and vim-go for Go. There has never been a problem with tabs vs spaces. On save gofmt converts all spaces to tabs and when I open Go files in vim-go it converts them to spaces according to my settings. Same for all other editors, whether you like tabs or 7-space indent.

Pretty sure it was a joke...

Right. After reading so much Go hate I'm not sure who is serious anymore.

Poe's Law strikes again...

or python, or rust.

Python doesn't care either way as long as indentation is consistent (though there's a common misunderstanding that Python cares). However PEP-8 specifies that code should be indented using 4 spaces and editors should be configured to render tabs as 8 spaces (likely to make mixed tabs & spaces really obvious). But PEP-8 also specifies that code should follow whatever is the coding standard in a given project.

IOW, Python is actually far more pragmatic than most people (including most Python programmers) think. It just has a culture that strongly advocates following the rules (i.e. PEP-8 and PEP-20).

Python treats a tab character as the amount of spaces needed to go into the nearest multiple of 8 column. With py2 ability to mix different indentation as far as it amounts to the same column, you can format your code in pretty interesting ways.

Well, python most certainly do care in the case when tabs and spaces are used inconsistently. In python2 you could even redefine tab width inline like https://gist.github.com/yxhuvud/2006599 .

Using Python for 10+ years, never used tabs.

My other personal feeling is that it's easy to auto-check we aren't using tabs (just search for tabs, and reject if any are found).

Depending on how you choose to format, it can be arbitrarily hard to check tabs are being used correctly.

For example, many people want to do some space indenting, such as:

    <tab>void my_function(int arg1, int arg2,
    <tab>                 int arg3)
    <tab><tab>{

It's (I believe) impossible for a language-agnostic tool to know this is "correctly tabbed", but (for example)

    <tab>void my_function(int arg1, int arg2,
    <tab>                 int arg3)
    <tab>    {

Is not.

I just always enable "Show whitespaces" in any editor I use. https://i.stack.imgur.com/BP2WJ.png

This let's me know if I left any trailing tabs/spaces before committing, align code better and while writing not while "refactoring".

git commit -am 'Whitespace formatting changes only'

No.

Don't align.

    void my_function(
        int arg1, int arg2, int arg3,
        ...
    ) {

I also like a rule that states that you either put all the parameters on one line, or each one on its own separate line, but never something in between.

I don't think blindly following any convention is good. Sometimes it makes sense to group a few parameters, take this toy example for instance:

    void drawrect(
        Surface *surf,
        int x, int y,
        int width, int height,
        uint32_t color);

Grouping relevant arguments just makes it a bit more legible. It's even more useful when calling the said function (assuming function with a lot of parameters, say XCreateWindow).

While I quite like that style, now you have to convince people to never align, before you can convince them to use tabs.

I've not seen any large public code-bases uses this style, so it's hard to know how well it works in practice. Do you know of any major projects with a 'no alignment' requirement?

MediaWiki uses tabs for indentation and discourages alignment. https://www.mediawiki.org/wiki/Manual:Coding_conventions

I also much prefer this way of breaking long lines. Aligning parameters always looked ugly to me, specially with long function names.

Honestly I don't care either way just a long as the file doesn't mix tabs with spaces.

I hate when the code looks perfectly aligned in my editor but is completely messed up in git because git renders tabs a different with.

I personally prefer spaces on my own projects because in the early days a tab used to be fixed at 8 spaces and I though that was a bit too much.

It's adjustable now but I don't think it was then or at least I wasn't aware it was.