In this video, I’d like to show you that Pharo
also offers the possiblity to have an assistant that
checks your code quality, it is called either
the Quality Assistant, or Code Critics. It runs
automatically good practice rules on your code.
Let’s have a look at it more closely.
You’ve seen that each time you browse a class,
you have this pop-up that is displayed.
In fact, what happens is that automatically,
while I’m browsing,
(let’s choose CubHelix to see),you have
this little area here where indications
are displayed. And when I go on the package also.
As it is a little bit difficult to find a
convincing example, we will use our own code and
write ugly code in it, this way you will see.
If I go into Counter, let’s imagine for example that
I leave debugging code,
here the system tells me automatically 2 things.
It says that there is debugging code left
in the method. What can I do ?
I can understand where does this rule come from.
So I click on it, it tells me to use
breakpoints, which is not specially smart in production code.
It can tell me, I will automatically solve this problem.
Let’s try, we will see.
It says to suppress this.
Ok, very good.
And as a consequence, I don’t have this problem anymore.
You’ve seen that we do it while I am
programming. Finally, the system will react.
Now, there is another way to do it, I can
open the Critic browser on my package.
here it is a very small package.
Let’s make a mistake in order to see it.
Here if I do "self halt"
or far example I do another method,
I create an “increment3” method and
I invoke a method which doesn’t exist.
Let’s call it "foofoo".
So here it is red but let’s suppose I haven’t
noticed it because of a feverishness state…
I’m gonna use the Critic browser
on my code and here the Critic browser
shows me the set of rules.
There is in fact quite a lot rules
with explanations. If you have this code there, in this
case you’d better use it that way, if there is
an allocation inside.
There are several kinds of rules.
There are rules linked to optimisation, rules
that can potentially identify fixed bugs.
Rules that identify true.
If I go there, I see the code.
I can browse the definition as we did before,
or I can transform it.
And the warning disappeared.
Now it is important to notice that
all these rules are based on heuristics.
This means that sometimes you do things
that are not very good. You know it and you
have to let it that way in the system.
You can also say that this is a false
positive. Let’s imagine I have a “foofoo”
message and I know I want to keep it, I can
specify that this rule is false for this method.
I will write it.
Here it is in grey, what does it mean?
It means that later I could look at it
and say myself maybe this rule was true and
it made sense to take another
look at it.
We can save the critics.
It means we save the rules results and
as well the false positives.
When we write something was false, we don’t want
the system to repeat it constanltly
each time we run the rules.
So when I save the critics, it will put them in a manifest.
Let’s look at it. Here there is my manifest which will
be assigned a version associated with the system.
You don’t need to see how it is coded inside, we don’t care.
The Manifest enables to code things,but no matter.
You don’t touch to this, this is the code-critics that will use it
for the next executions.
And you have a manifest for each package.
When you assign a version to the code, you
also assign a version to your manifests, and when you
run again your code-critics, automatically it
will take into account all the false positives and all
the meta-remarks you put in it.
So what is really interesting with those quality
rules is that Pharo integrates them in a development process.
We will make sure that,
each time you commit your project, there are
Jenkins servers that will load and run
automatically those quality rules to check that
your program really follows those rules.