simplabs / excellent

This is something I don't really want to do. Excellent was made to make the code better, not worse ;) "Pragmas" like # excellent:ignore in the source would be something that Excellent would actually have to report as code smells.

There is a ticket that requests configuration files (#2), but I don't think it makes sense to go down to the class or even method level to enable/disable certain checks. This would soon become a configuration hell every time you refactor something, want to disable or re-enable checks, forget to do so after refactorings etc.

Yes, but think of a bigger project with maybe 1000 warnings. The team want's to build better code, but some warnings always be there as false positives. Now someone commits something and the warnings climb to 1010. We have to look, which of the 1010 are the new error, which are real warnings and which are false positives. After a few commits this number always will get bigger and bigger - this is not really satisfying for the programmers. But if you leave the number near zero, the programmer gets feedback like "Hey, there are THESE 10 new warnings from your code".
Of course you can simply add # excellent:ignore to all your errors, but programmers, who are pragmatic enough, to use tools like Excellent, will think twice to do so.

Yes, I see your point. But for situations like that I'm thinking about some "CI like thing" (it's still very vague) that only checks the files that have actually changed in the commit and will report warnings for that commit only. Then you might get maybe 30-40 warnings max for a bigger commit which is a number you can handle well even if you know 10 are false positives since you e.g. really don't want to validate anything in a specific model.

Again, see #2. I'll add config files to make it possible to configure which checks to run for

• all files in a directory where config files in subdirectories override configs in parent directories
• specific files

So if you really wanted to disable a check for a specific model, you would disable it for the file the model is defined in. This does not really have high prio right now however since there are some other tickets that are just more important (fixing bugs, adding specs etc). Patches welcome of course!