And maybe you can enforce no alignment, but that's a hard fight to win.
And as far as tabs for indentation and spaces for alignment, I've found no practical way to enforce this via tooling/linting. And a rule without enforcement becomes inconsistent, which is how we get files full of mixtures of spaces and tabs, which is how people get frustrated with tabs, and we decide to throw it all out.
And inevitably, that's part of how spaces "won"
To take this example from a sibling post:
if (foo) {
» frobnicate(bar,
» ...........baz);
}
if (foo) {
» frobnicate(bar,
» » » ...baz);
}
Checking for that requires something more like a linter with a detailed understanding of the syntax parse tree.
For example, I considered writing a small Awk program to check C code in response to another poster’s complaint about lack of tooling, but then quickly came to the conclusion that, with C’s insistence that (say) /??/<newline>* is a valid comment starter, getting this exactly correct probably does need an actual lexer that would go character by character. That sounded like it wouldn’t fit in an HN comment, so I stopped there.
(That said, that’s as far as you’d need to go in the majority of cases. A dishonorable mention is warranted for languages that use the same character as an operator and a paired delimiter simultaneously, that is C++, Java, C#, TypeScript, and Rust with their abuse of the less-than and greater-than symbols, because that would in fact require a parser. In C++ especially, you’ll need full semantic analysis with template expansion, name resolution, and consteval evaluation. Because C++.)
Yet you probably don’t actually need to be that accurate, do you? The majority of syntax highlighters aren’t, and they are still useful. You can usually afford to say that code that perverse deserves to lose, and in return I expect you should be able to gain a fair amount of language independence, which could be worth the tradeoff.
So instead of checking if things are aligned with what they should be, you would just check they are aligned with something, like a left word boundary preceded by a delimiter, and so on. I can already see unpleasant corner cases after thinking about it for a few minutes, but it doesn’t look hellish yet, it looks something like you could experiment with over a weekend to see if it was viable.
Anyhow, if code reviewers always use tools that highlight the tabs during the reviews, there's a good chance to catch these things.
Maybe you could also have the tab width set randomly at every review, to make these horrors stand out
Addind a comment with the right amount of tabs as a table header and align all fields with spaces after the tabs would do the trick.
if (foo) {
» frobnicate(bar,
» ...........baz);
}
Of course that will always be a compromise, either people who use narrow tab widths or those who use wide ones will have a (slightly) suboptimal experience.
No wonder why spaces "won"
I am fine with a (single) space being an important part of syntax, just don't use more than 1 please.