no-tabs makes it hard to comment out code

[edg2s]

Commenting code line-by-line results in tabs in comments, which trigger a warning :/

[Krinkle]

Hm.. I'm struggling to see what this rule is trying to catch given we use tabs for indentation.

Apart from indentation, tabs can appear in comments and as whitespace separation between syntax. It seems that in comments we would want to allow it.

Between pieces of syntax we want to disallow it. But, I'd expect other rules to catch that already. E.g. a tab between function and () would presumably be caught by rules like space-before-function-paren and such. Just as a new line or multiple spaces would also be caught that way.

[jdforrester]

Between syntax we want to disallow it. But, I'd expect other rules to catch that already. E.g. a tab between function and () would presumably be caught by rules like space-before-function-paren and such. Just as a new line or multiple spaces would also be caught that way.

Sadly they didn't, hence why we spotted a couple of issues when applying this in repos, e.g. in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/475911/1/modules/all/ext.wikimediaEvents.citationUsage.js

I'm not totally happy with how much this made us re-write code comment blocks, but the work is done, and I don't think reverting is worth the effort.

[edg2s]

Yeah - it caught other errors like var x =\t1; and /*\tComment */

[jdforrester]

Per discussion, can we just mark this issue as Closed?

[Krinkle]

It should be valid in our rules by default to have documentation blocks that have indented code, and to be able to comment out multiple lines of code with // . In both cases there will be lines like such:

\t\t// {
\t\t// \t"key": :"val"
\t\t// }

and

\t\t/*
\t\t * {
\t\t * \t"key": :"val"
\t\t * }
\t\t */

Unless we change that coding convention, I'm not sure violations from this all over the place are worthwhile the small gain in not having accidental tabs elsewhere in the code. I expect those to be rare mistakes, caught in code review, or otherwise fairly harmless to the readability and quality of the code.

So my preference would be to disable the rule, and then invest in space-before-function-paren instead to be able to detect incorrect types of whitespace (such as tabs and newlines) where we have codified a space to be used.