Hi, I'm working on SmallLint. I have several ideas for improving SmallLint: The correction of some rules can be automated (eg Rule Unnecessary "= true" or Variable not reference) -> add transformation to these rules. 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?) Adding an indice of difficulty to correct the rule: - Level of automation for the correction of the rule (automatic, semi-automatic, â¦). - Scope of the rule (block, method, class â¦). 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 ...) 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. One could also think on how to efficiently visualize the results of smallLint ... Simon Allier
Hi Simon,
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. One thing to improve here would be the spell checker: Critics only uses a decent spell checker on OS X, where the one from the platform is available through a primitive. On all other platforms a very stupid spell checker based on a word-list is used.
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.
- Scope of the rule (block, method, class â¦).
Not sure what you mean, but you can scope the rules to any RBEnvironment (see http://www.lukas-renggli.ch/blog/programmatically-run-lint).
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.
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. 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: http://jenkins.lukas-renggli.ch/job/Seaside%203.0/791/checkstyleResult/. Cheers, Lukas -- Lukas Renggli www.lukas-renggli.ch
Lukas 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 http://www.lukas-renggli.ch/blog/programmatically-run-lint).
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. We brainstormed For now we would like to add ManifestoofPackageXXX 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: http://jenkins.lukas-renggli.ch/job/Seaside%203.0/791/checkstyleResult/.
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. Stef
Cheers, Lukas
-- Lukas Renggli www.lukas-renggli.ch
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?
The RBTransformationRules are specified as a rewrite rule, so in the end they are an undo-able refactoring change.
- Scope of the rule (block, method, class â¦).
Not sure what you mean, but you can scope the rules to any RBEnvironment (see http://www.lukas-renggli.ch/blog/programmatically-run-lint).
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.
I think the cost is hard to assess for a tool. It is basically zero if a refactoring can be instantiated to fix it, but for many code critics rules there is no such refactoring. A critics rule is merely a suggestion of how the code could possibly be improved.
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.
Jenkins also uses it. All Java tools have a severity flag, so I had to add it. Have a look at source of FireBug, it even goes further (don't remember how).
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.
Yes, the pragmas are not really ideal, because most of the time you don't want to see that kind of annotations. What is available in the repository mentioned is an abstract test case with a test for each critics rule. Projects would subclass that test and override a method returning a default environment to run code critics on. Then you had a little DSL where you could enable/disable certain rules. And you could modify the default environment for each rule individually, that is to add/remove classes, class hierarchies, methods, method prefixes, method patterns, etc. It was basically a manifesto (it could also contain project specific rules) in the form of a runnable TestCase. We used this system successfully for the Cmsbox. After careful configuration we had a system with zero code critics failures. And the build system immediately barked if a new failure was introduced; or an expected one was removed. Lukas -- Lukas Renggli www.lukas-renggli.ch
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: http://jenkins.lukas-renggli.ch/job/Seaside%203.0/791/checkstyleResult/.
How simon can help concretely?
Make it possible so that code critics can run on-the-fly in the code editors (pretty standard in any IDE today). I had that in Helvetia, but that code depends on the whole Helvetia stack depends on the old editor. Lukas -- Lukas Renggli www.lukas-renggli.ch
participants (3)
-
Lukas Renggli -
Simon Allier -
Stéphane Ducasse