I tried to spark some debate in relation to my blog post on Perl::Critic and Subversion.
Only a few people responded, but at least it was some very good responses. Clearly one of these two-camps discussions, but the positive thing is that both camps have valid arguments and this is good since then people evaluating the practice if using Perl::Critic in pre-commit hooks can weigh these against each other and try to map them on to their local organization and practices.
As Jefffrey Thalhammer formulates it:
Teams should use Perl-Critic in whatever manner best suits their collective values, abilities, and priorities.
Pros:
- Strict control of code base
- Enforcing of coding guidelines for common code base
Cons:
- Latency in productivity
- Redtape over productivity
Both camps can however agree on several aspects are good practices, such as:
- Use of version control
- Unit-testing
- Continuous integration (CI)
And of course that static analysis is a good thing, when used properly.
This does not seem as many arguments, but many of the arguments in this debate are more or less related to the general use of static code analysis and do therefor not weigh in as arguments for or against the configuration of a pre-commit hook.
Ovid gave some marvelous input and then disregarded the whole debate as silly, saying that the pre-commit hook should assist the developer in making the right judgment, so he or she could choose to or not to commit.
From Ovids comment I do however deduct a very interesting aspect of programming and that is that programming is a very subjective activity and different developers would probably be able to implement the same functionality in very different ways, rendering different results when subjected to static code analysis.
I have passed on Ovid’s very pragmatic approach to Alexander, who’s CPAN contribution sparked the whole thing. And one of the more important things we can all agree on and that is the tools must be flexible enough to accommodate all camps. Perl::Critic is such a tool, so a pre-commit hook should be implemented in the same spirit.
The whole discussion seems to be leaning on the discussion on what quality really is, since this definition does seem to make the foundation for use of static analysis. This is again a very subjective discussion, which probably have even more camps, so we better not start a flame war about that.
All in all we can agree not to agree, so in regards to Jeffrey’s quote above I think we can conclude that the tools are there, put them to good use in the way, which makes the most sense in your situation.
Please feel free to chip in if you have an opinion on static analysis used in pre-commit hooks for SCMs.
0 Comments.