-Hi. In this video, we are going to look at the automated tools Pharo provides
to critique your code and give you some direct feedback or automated feedback.
For example, I loaded the MyCounter we developed in the redo of week 2.
If you go to Counter and, for example, the increment method,
if we write some debugging code, if we leave some debugging code
such as "self halt", so a breakpoint. If we save this,
we will see a warning there saying
that there is some debugging code left in the method,
and you can look on the question mark, click on this,
it will explain what this really is. So: "Breakpoints, logging statements, etc.
should not be left in production code".
You can click on the tools to get a direct resolve of issues.
Let's click on it.
You can see that this tool modified the increment method
and basically remove the call to "self halt". So, Ok.
It goes back to normal.
Now, if we call a method that has not been defined.
For example, "self undefMethod".
If we save this piece of code, we will see a new warning:
"Super and Self Messages sent but not implemented"
and "Messages sent but not implemented".
Basically, it really does not understand what this undefMethod is.
You can look at what those warnings are by clicking on the question mark.
"Checks if messages sent to self or super exist in the hierarchy"
and this "Checks for messages that are sent,
but no class in the system implements such a message".
Basically, it does not recognize the undefMethod.
What you can do now... Let's just leave this in the method to see.
What you can do now in your package is right-click and go to Browse critiques.
If you click on that, you will have a Critic Browser that will open
that basically lists all the rules that Pharo defines
and runs them against your package. There are lots of them.
For example, if we go to Bugs, you have a lot of them.
You can read them and see what they are or what they mean.
A thing that is really nice is
that if you know that this is a rule that is wrong for your package,
you can simply mark it as wrong. So, that is basically a false positive.
You can mark them as wrong and then you can save these critiques.
If you save them:
"Do you want to save all false positive and toDo?". Yes.
This will create a new class in your package
which is called "ManifestMyCounter",
that basically holds all the false positive
and things that you just stated in the critiques,
and that you can later on version
and integrate in your continuous development cycle.
In this video, we learned how we can use the automated feedback
on the window under your code
and how we can use the Critique Browser to version
and integrate in a wider continuous development process
in order to certify that your code still does not break the rules
when you push it.