So I spent a few hours studying my first module, the Test::Pod, and produce a few commits to make some small changes to the existing code in order to improve it (or at least, I hope so). The pull request can be found here.
Despite these small changes, I'm detailing here the approach I will try to use as a checklist during the challenge, in order to make it a path for learning and for not-breaking things:
- run all the tests in the distribution, in order to see if there is any failure (it should not be), and if so, start from such tests;
- search for open issues/tickets, and see if any of them is good for work on;
- read the dist documentation, see if it contains typos and/or errors and/or missing parts;
- read the code and see if there is something obvious that can be improved (e.g., use strict);
- inspect the code and see if it does what the documentation says.
Of course, it is required to iterate on each step and, of course, to test every single change against the test suite (and maybe provide a new test for that).
It is important to not produce work for the original author, and therefere:
- do not change code only because I would have written it with a different name, logic, conditional or alike. Try instead to make code more concise keeping readibility;
- do not provide code that breaks and test every single change at least for what it is possible and for what is the understanding of the problem and of the language;
- commits must have a good description of every single change, so that the original author can understand what was the intention of every change;
- keep commits as small as possible.
I'll refine the above checklist as I go on the challenge.
In the meantime, a few utilities can help in the work, most notably perlcritic, perltidy and Devel::Cover and Devel::NTYProf or similar.