simplabs / excellent

removed complexity and for loop checks, all other checks probably make sense to be run by default

duplicate

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!

I think more than one option to configure what checks are applied should be implemented. Actually the following make sense in my opinion:

• placing a config file in the directories that are scanned (where options in lower directories would override those in higher ones)
• having switches in the executable
• making it configurable in the rake task

One more option should be available:

• configure which checks to run for certain files (would override all settings that have been made on the file's directory tree).

also see #13

Since only Ruby syntax highlighting is needed, the syntax gem might be pretty good for this task: http://syntax.rubyforge.org

Or http://coderay.rubychan.de/

see a387715

The syntax gem looks actually better suitable for Excellent than coderay. IT's smaller, doesn't implement all the languages we don't need anyway etc.

One thing that has to be done would be to include line numbers though.

Jep, detection of initialize methods is not working sufficiently as of now. I will try to look into that in the next days.

Thanks for the report!

Cool, of course you're very welcome to contribute!

It woulc require some refactoring though to add a loc counter that counts ALL lines (e.g. sum of all lines in all files that are parsed) since the current implementation is really file and element based (class, method). It should still be possible though to extend Excellent in that way.

I already thought about graphs etc. A good way to do that might be something like http://raphaeljs.com/ where the complete graph creation could take place in the HTML formatter.

Great to have someone willing to contribute!

Okay, I did some research into the possibility of counting things like comments. Ideally it looks like the solution would be to switch from RubyParser to Ripper --the official parser shipped with Ruby 1.9. Ripper has a scanner mode which can be user to analyze source character by character. Unfortunately it doesn't look like Ripper can be made to work with 1.8. If that is indeed the case, I suppose the only option right now is to add a separate loc parser. Thoughts?

Love raphaeljs.com btw, I was thinking google chart api, but raphael is much cooler.

See 8030fbb.

This is the new spec scheme for the code processor. For each file that parses correctly, add a new check like the one currently implemented.

line numbers with sydparse:

parser.sexp(true, false)

sexp(true, true)

will also include the file name

Would also be great to reuse Rubinius' Melbourne parser (http://github.com/evanphx/rubinius/blob/master/lib/melbourne.rb) to generate an AST from sydparse's output. That would remove the need for excellent's own implementation (which is actually the most important and most fragile part at the same time).

Have to check if that's possible and if it could be done without license issues.