Sounds good in theory, but I never saw a project that used tabs and didn't look like a complete mess when viewed with the non-blessed tab width.

It's fine as long as you don't use tabs for visual alignment. Especially C projects tend to do this, and/or have a weird mix of tabs and spaces (e.g. indent by four spaces, but all eight spaces are tabs). That's just silly.

But if you just always indent by n tabs, and align with spaces for visual alignment, then it's not a problem. This is what e.g. gofmt does.

Pretty sure the Linux source tree looks fine at a tab width of 2 instead of the blessed 8.

Emacs even "helpfully" auto-converts <tab width> spaces to one tab, no matter where.

The problem with tabs is that you can't really do alignment with them, unless you have elastic tabs (which are pretty much nowhere). I love the idea of tabs for indentation and spaces for alignment, but even bringing up the idea of using both gets one branded a heretic, so that's out. Which pretty much leaves only spaces if you want to allow for alignment.

I'm really sceptical of the idea of mixing two different invisible characters in the same file, which is why the tabs+spaces idea makes me feel slightly icky. But another option is just not using alignment spaces at all - if you want to align two parameters/statements/etc, you always split them onto their own lines and use indents directly instead of alignment.

In other words, instead of:

    def my_func(self,
                param):

You always do something like:

    def my_func(
        self,
        param,
    ):

I tend to agree that you shouldn't be "aligning" things with spaces anyway. If nothing else, it causes diff pollution when the length of a line changes and you have to add or delete spaces to adjacent lines to keep things even, even though no semantic change to those lines has occurred.

However, regarding "mixing two different invisible characters in the same file" - you can, and should, configure your text editor to display tabs in a visually distinct way from spaces. Kate (my favorite) shows them as chevrons. Geany and Notepad++ show them as arrows. Not only does this make it easier to scan vertically along an indentation level, but doing so also makes it glaringly obvious if a pesky space has snuck in, resulting in a jarring misalignment.

> If nothing else, it causes diff pollution when the length of a line changes and you have to add or delete spaces to adjacent lines to keep things even, even though no semantic change to those lines has occurred.

While I agree with this in general, I find making the code nicer to read to be more important that avoiding diff pollution. Especially when that diff pollution can be avoided with a simple "ignore whitespace" in most cases.

I get that if I'm truly mixing one and the other, but if I'm consistently using tabs for indentation, I mostly want them to be invisible - I don't want visual noise on every line. I guess if the syntax highlighting makes them subtle enough it could work, but I think that sort of visual distinction only really works if the visually distinct character only rarely shows up.

I tend to prefer the former, but it suffers from the indentation being way to large if the method name is really long.

That being said, there are other cases where I want to align things and "a specific size indent" doesn't work

SQL

    SELECT this_column,
           that_column
    FROM tablename
    WHERE this_column = 1
      AND that_column IS NOT NULL

Comments

    /* 
     * Blah blah blah
     * Note: this is interesting because (enough text to want newline)
     *       and also that blah blah
     */

There's lots of places where "alignment" makes sense.

For the SQL case, you can just use a different formatting that puts aligned items into blocks, something like:

    SELECT
      this_column, 
      that_column
    FROM tablename 
    WHERE
      this_column = 1
      AND that_column IS NOT NULL

(The AND token could go either where it is, or at the end of the previous line, depending on your preferences - I prefer the clarity of putting the operator first here over the alignment of the column names, but I can see both sides.)

It might not be your preference, but that's always going to be the case with formatting.

With the comments, that's a good point. I'd generally prefer to use double comments for anything that spans multiple lines, but if you're creating a formatter you need to handle any syntax thrown your way. You could try formatting it without the leading space, but that would be very unusual, or keep the leading space and have it as the one exception to the rule. Or just not format comments, I guess.

For what it's worth, this is how the built in and mandatory Go formatter works and it's "fine".

If you can also get your colleagues to do things like putting their `&&` style logical operators on new lines, then tabs for indents works really well.

(This isn't the best example of what I'm getting at, but it's easy to grasp. A stronger example would be the use of ternary operators with multiple lines of JSX. There are many "micro-syntaxes" or "micro-layouts" that help readability and form common patterns in code bases which don't play well with tabs-for-indents, so when you use tabs, you have to train your team to develop and accept novel versions of these "micro-layouts".)

8?? His neck must be sore.