simplabs / excellent
- Source
- Commits
- Network (3)
- Issues (10)
- Downloads (11)
- Wiki (31)
- Graphs
-
Branch:
master
Sort by:
Priority
Priority
|
Votes
Votes
|
Last Updated
Last Updated
Loading…
-
I think it would be great, if programmers mark specific lines of code to exclude from the check. So they can at e.g. "# excellent:ignore" to a method to skip flog test or to a model to skip validation check.
Of course, everybody has to check for himself, if he use this to "make the checker silent", but also it provides the possibility to reach zero warnings. For example checkstyle in the java world does this, too.Comments
-
1 comment Created 2 months ago by marcoowadd highlighted source to the HTML formatteroutputx -
RDoc should explicitly describe the extension API that is available for adding more/ custom checks
Comments
-
1 comment Created 4 months ago by marcoowchecksxLook over which tests are executed by defaultmarcoowxMaybe the complexity checks should not be executed by default since they produce tons of output that is usually of little help. Maybe other checks should be excluded from the list of default checks too
Comments
-
0 comments Created 4 months ago by marcoowchecksxCheck for custom initializers in ActiveRecordmarcoowx -
0 comments Created 4 months ago by marcoowchecksxChecks for use of params[:x] or session[:y] in views/templatesmarcoowx





This is something I don't really want to do. Excellent was made to make the code better, not worse ;) "Pragmas" like
# excellent:ignorein 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:ignoreto 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
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!