Perl is famous as a programming language for letting its users code as they like. The mantra every Perl developer knows is There Is More Than One Way To Do It (even though, it looks like these days, some popular Perl developers are upset when you bring a new solution to a problem, but I digress).
My point is, Perl is like water. It will fit in your bowl, whatever its shape. It’s a language that will reflect your way of thinking most than any other language. I know some Python developers that are pretty in love with their language just because of the opposite spirit: in Python, there should be only one good solution for any given problem. That’s what they like, and what comes together with this philosophy is a very strict language that forces you to be a good citizen.
I can understand that. Strictness is a very good ally for a developer. But I want my strictness. Not the one that comes with the box. The strictness of my programming should be as I want it to be, it’s personal, and if I’m in a team, it should be a set of rules everyone are aware of.
This is were, again, I’m very happy to use Perl.
A couple of weeks ago, at work, I wanted to set a strict Perl environment for my everyday needs. I ended up writing a pre-commit hook that has the following features:
- filter the code with PerlTidy
- prevent any commit that violates a Perl::Critic policy
- run the test suite with Devel::Cover and make sure the total coverage rate is not lower than it was before the commit
Of course, as I said above, I want my strictness, so PerlCritic and PerlTidy use respectively .perlcriticrc and .perltidyrc in the local directory, so I can tweaks the rules on a per-project basis.
After two weeks working with this hook, I realize that my code is now much more robust and very well tested (100% coverage is easy to reach when you start working on a project like that).
If anyone is interested in this commit hook, it’s on GitHub.
How long does the commit now usually take? How often do you commit during the day?
I like this idea, but I’m afraid it is too slow.
You’re right that it has a cost, depending on the time needed to run the test-suite. On small projects it’s acceptable, so I use that pre-commit hook, but on larger ones (like Dancer for instance, which has more than 1k tests) I run the full pre-commit only before a push.
That’s a matter of compromise actually. Running only PerlTidy+PerlCritic before each commit is acceptable I think, because it’s ran only on the commited files.