stephane.ducasse at inria.fr
Tue Jan 10 18:22:40 CET 2012
Tx for the feedback.
>> The correction of some rules can be automated (eg Rule Unnecessary "= true" or Variable not reference) -> add transformation to these rules.
> Yes, that would be nice.
>> Some rules such as Spelling rules (eg comments Method: Checks for spelling errors in method comments., 7088 problems) are not very interesting and could be removed (or treated differently?)
> I like them, but if you don't want the spelling rules you don't have
> to load or run them.
The question is how the package specifies what rules should be run.
I think that packages should be able to state
their false positive and the rules that they do not want to be run on them.
>> Adding an indice of difficulty to correct the rule:
>> - Level of automation for the correction of the rule (automatic, semi-automatic, …).
> Actually this information is there: rules correct automatically if the
> rule is a subclass of RBTransformationRule.
Ok good to know. Are they linked to a refactoring?
>> - Scope of the rule (block, method, class …).
> Not sure what you mean, but you can scope the rules to any
> RBEnvironment (see
This is not in that direction but more.
This rule may impact method, classes…
One idea is can we propose a way to assess the cost of fixing a violated rules.
Not easy since some of the rules are trivially fixed but may report a lot of violated places
while a rule can be difficult to fix and only get to one place.
Still we would like to give some hints to the maintainer.
>> Other costs could be
>> - cost of applying (may be the rule requires to compute something else, or if a rule has 50000 hits, it generates an extra cost to analyze the results)
>> - cost of NOT applying the rule (if it could detect a bug and we don' t apply it ...)
> There is something like this in RBLintRule>>#severity. The severity is
> shown as an icon in OB.
Ok we should use that.
>> Adding a manifest to manage/mark falses positive:
>> - one manifest (a class) by package.
>> - Manifest: exclusion of class/method of the package for rules or for all the rules.
>> - Exclusion of rules for the package.
> See http://www.lukas-renggli.ch/blog/ignoring-lint-rules.
> Also many years ago I wrote some infrastructure to run critics rules
> as part of the tests, what essentially served as a runnable manifest.
what was it?
How did you manage false positives. What we want is to add a package Manifesto to store false positives.
Because we should not use pragma for that because we will have tons of pragmas everywhere.
Then the package should also declared which rules not to run (or the inverse - any suggestion is welcome).
Then also resolve the problem of ignoring completely classes for example. Now the manifesto could hold more information such as
documentation, license…. other metadata.
For now we would like to add
to each package
add into it a data structure (may be under the form of methods).
We could also easily strip out Manifesto for shrinking purpose. Now what is not good is if we want to store evolution of violation
because the package should not get dirt each time a rule is run.
Finally we are not sure if we want to have inside the package or on a separate package. I prefer inside to always ave synchronized metadata.
and less packages to manage.
> The code is in http://source.lukas-renggli.ch/essential.html, but it
> likely needs some fixes to make it work in a recent version of Pharo.
>> One could also think on how to efficiently visualize the results of smallLint ...
> See for example the SmallLint results of Seaside 3.0 run by Jenkins:
How simon can help concretely?
Right now we will prototype the idea on a couple of packages to see how it works.
After we will report what we did and the result.
I would like that we converge. And after that we would like to have an integration server running systematically
the tests and the rules.
> Lukas Renggli
More information about the Pharo-project