Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Version 2 of QualityAssistant brings some core changes of critics handling. These changes come from Renraku model. QA v2.0 is already integrated in Pharo5.
QualityAssistant needs early users and feedback to become better
Now you will see more than one critic of the same rule, if there are multiple violations.
###Highlights & Prefixes
If possible, the critic text will be prefixed with the name of the faulty part (variable, message, method, etc…). These prefixes as well as source code highlights are not implemented for many critics, although it is possible to do it. If you will find such a case, please report it here: https://github.com/Uko/Renraku/issues.
Autofix got more sophisticated, it can provide more solutions than just ones available in transformation rules. However, previewing changes (i.e. before-after diff) is not as nice as it was. Sorry for inconveniences, I hope that we will have a solution for this in the future.
###Inspector & Spotter Plugins
Now the plugins in Inspector and Spotter can be toggled in settings (QualityAssistant group) and are disabled by default.
Now each rule outputs critic objects. Each critic knows which rule produced it, and which entity it is about. Also critics can tell whether they provide an interval and a change (and allows to access them). The interval is a faulty part interval in the source code (that can obviously be used to highlights). The change is a
RBRefactoryChange that should solve the critic once executed.
It's each rule is responsible for providing it's own critics. Basic critics can be reused, but if desired a rule can use it's own perfectly tailored critic.
There are 4 method that can be used to obtain critics:
check: anEntity forCriticsDo: aCriticBlock ifNone: alternativeBlock
check: anEntity forCriticsDo: aCriticBlock
check: anEntity ifNoCritics: alternativeBlock
First method checks
anEntity, and performs
aCriticBlock for each critic of
aCriticBlock may be 0 or 1 parameter block. In the latter case a critic objects will be passed to the block. In case no critics are found
alternativeBlock with be evaluated. This is the method that should be implemented for each rule, the other methods are there simply as shortcuts. Methods #3 and #4 return a collection of critics.
Note that developers are encouraged to implement
#check:forCriticsDo:ifNone: in an efficient way, such that
aCriticBlock is evaluated as soon as a critic is detected. In case of complex computation and no need of details, a user of rules can return from the method on a higher level as soon as a first critic is encountered.
As you have noticed there is a single method that should be redefined to check an entity as opposed to SmallLint's
checkMethod:. Quality rules should define on a class level which entities they are checking. At the moment
#checksMethod. Both methods return
false and should be overridden to return
true if they have to check classes or methods respectively. In future there will be more entity types such as Packages, MetaClasses, Traits, etc... This allows to have a rule that works for both classes and traits, or another one that works only for meta classes.
Rules may tell that they provide a change. This is an
RBRefactoryChange that can be executed to solve the critic. At the moment the preview diff is created with a very basic text diff which was taken from Changes Browser. On the other hand an
RBRefactoryChange can in fact contain many changes and so provides a flexible possibility define your own automated fixes.
Critic checking got much faster. First of all rules are not storing critics in their environment and retrieving them later. Secondly the rules of classes are not doing empty run on methods and vise versa (which is not that significant, but still nice).
Many subscriptions and singletons were improved.
The image is now nearly 1MB smaller
© Marcus Denker
This update takes into account recent changes of Nautilus announcements. This results in faster operation and less errors when removing classes/methods.