|Syntactic Confectionery Delight|
Re^8: Modern Perl and the Future of Perlby jplindstrom (Monsignor)
|on Dec 22, 2007 at 17:45 UTC||Need Help??|
If you need Perl::Critic to enforce a coding style, you have a problem that lies elsewhere.
No. Because people make mistakes. Not all of the time, but some of the time. I'll give you an example.
Perl::Critic runs every time I open a file and highlights, directly in the source code, whenever there is something to complain about according to the policies I haven't disabled (which I spent quite some time doing in the beginning).
But nowadays I never think about this because 99% of the time there is nothing to report and Perl::Critic is silent.
But sometimes there is something to report and one of the lines of code is blue, begging for attention.
Several times over the last couple of months I've opened files in our code base at work and seen the warning that there is "code before strictures enabled", i.e. no "use strict".
Now, most of these have been five-liner .t files used to set up a test framework. So no biggie, no harm done, nothing was really broken.
But one of the files was a proper module where someone had missed to "use strict;". There was lots of code without strict. And sure enough, when I added it, the source didn't compile because of an undeclared variable.
So Perl::Critic actually helped me find a bug which was introduced by someone making a mistake.
Now, having this little aid will prevent me from making that particular mistake.
I have loads of little guidelines, conventions, and heuristics for how to do things in order to not screw up all the time. Very few of them happen to be Perl::Critic policies, and just a few of them would be useful to implement as policies, but for the ones that makes sense... why not?
Having said all this, I share your concern that Perl::Critic policies will be used as "rules" rather than "guidelines" (but as usual, you have to know why the rule is there, or that there is a rule to break in the first place before you have earned the right to break it).
I also see the risk that in some environments / organizations / projects Perl::Critic policies risk being something imposed on programmers from above, rather than embraced from within the team itself.