This is the approach I took when I was teaching myself C in the late '90s. Indent with tabs, align with spaces intuitively made a lot of sense.
Then I started using code formatters, initially `indent', then vim plugins. Eventually, I found myself using Visual Studio professionally, and became content letting the IDE decide how code should be formatted. Now, I do whatever the language/community seems to prefer. For .NET stuff, Visual Studio defaults; Go and Rust have their own formatters, RubyMine defaults for Ruby, etc.
Everywhere I've worked whenever the code formatting debate comes up, "use the IDE/compiler/community standard" always wins the day. The hardest thing seems to be convincing Windows users that text files need to end with a newline. Is there a git option (like `autocrlf') for that?
You can set up an Editorconfig[1] file to automatically fix trailing whitespace and insert the final newline, among other things. Most editors have support for it (either built-in or in a plugin).
It's a lifesaver when you care more about formatting than any of your coworkers and can set up something that handles it for them.
Additionally, configuring editors/IDEs to format code when the file is saved is very useful to enforce formatting rules.
I had the same experience with Java and its looong lines of AbstractFactoryFactoryBuilders. Tabs + spaces offered the best of both worlds, and enabling whitespace visibility.
In the end it doesn't matter what's my preferred way of indenting code, the hardest part is always making people agree on it. So whenever a new project starts and the team needs to define code styling, we go with the language/IDE defaults. Anything else requires IDE setup and attention to indentation, which is too much to ask for when people barely pay attention to code quality.
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.)
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.
> 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.
Back in 1978, with 300 baud modems, we wanted to minimize the number of characters transmitted. Peterson, Bitner, and Howard reported[1] in Communications of the ACM their algorithm to optimize the tab stop columns for a text document. They observed reductions of 7 to 30 percent of the number of characters transmitted.
Then I started using code formatters, initially `indent', then vim plugins. Eventually, I found myself using Visual Studio professionally, and became content letting the IDE decide how code should be formatted. Now, I do whatever the language/community seems to prefer. For .NET stuff, Visual Studio defaults; Go and Rust have their own formatters, RubyMine defaults for Ruby, etc.
Everywhere I've worked whenever the code formatting debate comes up, "use the IDE/compiler/community standard" always wins the day. The hardest thing seems to be convincing Windows users that text files need to end with a newline. Is there a git option (like `autocrlf') for that?