[jomar]

This is nice in theory, but it will inevitably get screwed up by your less details-oriented coworkers.

The spaces and tabs are mostly invisible, so even if they did care about it these people can't really see the conventions that are in use. So the source code will inevitably accrue indentation done via spaces mixed up with the good lines indented via tabs, and then it's game over.

A script I have been working on lately is mostly tab-indented but has space-indented tracts and individual lines mixed in as it has been worked on by multiple authors over the years. When I started working on it, I thought the indentation was just plain borked (with the subclauses of if statements indented less than their if lines, etc). But then I discovered that setting tabstop=2 made most of the space-indented lines line up properly -- turns out this script was written to a 2-space indent (crazy narrow by my standards!) using tabs, with a few space-indented lines mixed in on the same scheme. Until another author came along some years ago with their tabs set to 4, and added some space-indented lines written to line up with the 4-space tabs they were looking at. So now there are several incompatible categories of space-indented lines in this 200 line source file.

The real argument from the spaces camp is that their approach is the only realistic compromise with reality: by banning explicit tab characters in source files on disk, there is no room for error.

(Except that the same coworkers are wont to include trailing whitespace or omit the final newline, but at least that sort of invisible difference does not affect reading the indentation.)

[Sharparam]

> Except that the same coworkers are wont to include trailing whitespace or omit the final newline

Editorconfig[1] makes this a non-issue.

[1]: https://editorconfig.org/

[WalterGR]

> This is nice in theory, but it will inevitably get screwed up by your less details-oriented coworkers.

A syntax-aware formatter could detect that, right?

[jomar]

The scheme proposed in TFA is not particularly amenable to automation:

> Can I programatically convert from what I use now?

> Unfortunately, probably not

Moreover, even if a syntax-aware formatter could detect mistakes made in following this scheme, that presupposes that these coworkers will actually use said tools.

Some of us work in organisations where it is not politically feasible to insist that everyone work in any particular way or adhere to any particular standards. Welcome to academia…

Or just consider whether everyone contributing PRs to an open source project will get this right or use such tools.

[WalterGR]

> The scheme proposed in TFA is not particularly amenable to automation

It is. The author just assumes syntax unaware tools. Moreover, that quote is about converting to the system, not automating it while writing code or maintaining it once established. (But syntax-aware tooling could do all of that.)

Re. people actually using such tools unless forced to, yes, that's definitely a whole other issue. Some organizations solve this by modifying the commit pipeline: auto-formatting code, or detecting and rejecting commits that don't pass muster.