- Several Monks suggested that Perl::Critic should focus on only the most offensive or risky coding practices, or else it might seem too alarming and annoying. So we've assigned severity levels to all the "Policy" modules. By default, Perl::Critic only complains about high-severity issues. Of course, you may not agree with our severity designations, so you can override them to suit your own tastes. And by increasing the severity threshold over time, you can gradually whip your legacy code into shape.
- We've also added a dozen new "Policy" modules. Most of these come from Conway's "Perl Best Practices." But we've also taken a few ideas from B::Lint. So I think Perl::Critic is starting to demonstrate its capacity to support a range of alternate stylistic views.
- This node about a use stricter pragma inspired me to create the criticism module to accompany Perl::Critic. At first I thought it was mostly a joke, but I'm beginning to think that criticism has real merit.
This fixes a bug I hit when installing Perl-Critic, which was actually down to PPI. Great!
I would recommmend that Perl-Critic be in beginners toolkits too, as it's very nice to just run this over your code and see if you may have done anything stupid.
It's so nice to see module authors working together with regard to releases, just look at the PPI changes for evidence.
I love the Perl community.
Gavin.
Fancy a yourname@perl.me.uk? Just ask!!!
A product I use quite a lot is FxCop for .NET. Ignoring the fact that it is for .NET it has some quite nice features.
One feature I like especially (hence my comment here) is that each rule can point to the FxCop website with a discussion on the guideline and a code example that:
- Breaks the rule
- Shows the fix
Perhaps this is something that could be added? Certainly links to perlfaq where relevant. I realise you are citing the PBP book and point people at the pages in there but why not extend it a little more? It may help newer programmers who may not have the book or have the book to hand. It would also allow you to add more rules that are not necessarily from PBP but from other sources of knowledge such as this site.
Just a thought :)
perlcritic --verbose=9 MyModule...will add a complete discussion of the policy (including examples) to each violation. These are just pulled from the POD of the appropriate Perl::Critic::Policy subclass. You can also customize the output format to your liking. See the "--verbose" option in the perlcritic docs for more details. Thanks again for the suggestion! -Jeff
my $foo = 1 if $bar;I've been bitten by that before, and never want it to happen again.
use warnings; use strict; my $t_bar = 1; my $t_foo = 1 if $t_bar; my $f_bar = 0; my $f_foo = 1 if $f_bar; print "true $t_foo false $f_foo"; #->true 1 false #->Use of uninitialized value in concatenation (.) or string ...
holli, /regexed monk/
Please forgive my ignorance, but what's wrong with it? $foo ends up as 1 when $bar is true and is undefined when $bar is false. Just as I expect it to be. (Active Perl 5.8.7)Wrong. This piece of code is one of the weird things in perl, in this case, something that is sometimes used as a dirty trick, to create a static variable.
#!/usr/bin/perl -lw
print $];
for (1 .. 5) {
my $i = 123 if $bar;
print ++$i;
}
Result:
Name "main::bar" used only once: possible typo at test.pl line 4. 5.008003 1 2 3 4 5
The following works as expected.
my $i = $bar ? 123 : undef;And yeah, that's really weird.
holli, /regexed monk/
Conclusion: Always assign something in a my declaration?
More precisely: make sure the left-hand side of a my in an assignment is never conditional.
Makeshifts last the longest.
It's not about the assignment. It's that my() should never be conditional. my $foo if $bar is just as bad for the same reason. You're just not likely to write that because it looks funny. my $foo ... for ... is probably also just as bad. The statement modifier form allows the my() to declare the variable for use by all following statements in that scope.
⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊
Always assign something in a my declaration?I think it boils down to: Never modify a lexical unless the my() was executed during the current execution of the enclosing block.