At my workplace, we have a lint rule that reports an error if is anywhere in the file, plus a commit hook that blocks all commits with anywhere in them. It works well and has saved me a few times.
Works pretty well, except the lint rule and its associated tests have to do something like "@no"+"commit" to avoid triggering it,
In a lot of modern work flows this is incompatible with the development pattern.
For example, at my job we have to roll a test release through CI that we then have to deploy to a test kubernetes cluster. You can’t even do that if the build is failing because of linting issues.
The test release shouldn’t have anything marked with though… The idea is that you use it to mark code that is only temporary local debugging code that should never be committed.
Are you committing to master? I don’t see any reason why you shouldn’t commit your debugging code to your own branch. Obviously clean it up before merging
