Elliot Shank via RT wrote:
Show quoted text> <URL:
http://rt.cpan.org/Ticket/Display.html?id=31977 >
>
> Michael G Schwern via RT wrote:
>> That's just the rule, not the reasoning. I dislike blindly following
>> rules, it's better to examine the argument leading up to the rule.
>> Rules are often situational. Once you know the reasoning behind the
>> rule you can know when and where to apply it.
>
> Then turn the rule off. If you don't agree with the policy, don't use it.
Somebody has to decide on the defaults.
Show quoted text>> The argument against octal comes from the idea that the user has
>> mistakenly used 0123 to mean 123. That they don't realize they can't
>> pad numbers with zeros. I've never actually seen that mistake, nor
>> heard that argument, but I'll accept that Damian has encountered the
>> problem when teaching beginners.
>
> You are not an average programmer. You'd be surprised by some stuff I've seen.
Not applicable, I'm not doing anything particularly bizarre here.
I disagree with the implied notion that perlcritic isn't useful across all
spectrums of abilities. To back away from the goal is to give "expert"
programmers (whether they actually are or just think they are) carte blanche.
As I pointed out earlier, it even did a good job on the hairball of
MakeMaker. There is value even to experts.
Anyhow, I agree with the general idea that 0xxx might be confusing. I
disagree that there aren't sensible exceptions.
Show quoted text> Your separate complaint about "no strict" is in this vein as well.
> Most programmers shouldn't be doing /anything/ that requires no strict.
> I'm very glad to be working with a language that supports things like no
strict.
Show quoted text> That doesn't mean you should be using it all over the place in average code.
Many programmers wouldn't even bother to turn it on in the first place.
At some point it's ok for perlcritic to read some of the more obviously
implicit "I know what I'm doing" rather than having to state it explicitly.
"Code before strictures are enabled" is a pretty well accepted bad practice.
Selectively turning off individual strictures in limited scopes is
speculation. If nothing else speculative critics should not be of highest
severity.
You can narrow the critique against turning off strict even more. There are
valid reasons to turn off strict references, even for mere mortal programmers.
Method generation isn't that hard and I'd rather teach that than see people
use AUTOLOAD which is what they usually reach for first. (Hey, does PC
complain about AUTOLOAD?... nope) But there's no good reason to turn off
strict vars or subs.
"no strict 'refs'" in a limited scope, ok. Any other use of "no strict", bad.
Show quoted text>> But as I laid out, this is unlikely to apply to someone using bitwise
>> ops. In that case it's A) getting in the way and B) missing the real
>> mistake which is using a decimal or string. Would you argue that
>> they probably DID make a mistake?
>
> The whole reason for the entry in PBP is to make your intent blindingly obvious.
> If, say, octal numbers were written using 0o777, things might be different.
There's obvious and then there's silly. Sometimes eschewing certain language
idioms in favor of "obvious" code can actually have the opposite effect.
So far everyone I've put the recommend code in front of:
$mask &= oct 755;
has scratched their head as to why someone would do that instead of 0755. I
would argue it has made it less obvious.
If there's a non-obvious part there it's all about using bitwise ops, not the
octal number.
It's like someone writing:
my $count = scalar @array;
You could argue that "scalar" makes it more obvious and protects you against
mistakes like:
my($count) = @array;
But this reasoning is speculative. The mistake is easily testable. The
"improved" idiom is verbose, not idiomatic and implies a fear of Perlish
thinking (in this case, embracing contexts). It adds in "scaffolding" code
(to use a Damianism) that really doesn't do anything. Finally, it is a
documented part of Perl.
Another example might be this:
if( foo(@args) ) {
do_bar();
}
One could argue that all the explicit parens make it "obvious" what's going
on. That may be so, but they also clutter up the space with lots of parens
and braces doing different things. Compare...
if( foo @args ) {
do_bar;
}
Or even:
do_bar if foo @args;
Then it's ok to have your parens back.
do_bar() if foo(@args);
Show quoted text>> Like tests, every false reading degrades my confidence in a tool's
>> utility. That's why I'm continuing to push for a fix in Perl::Critic
>> itself rather than hacking my own .perlcriticrc or spreading "## no
>> critic" around.
>
> Have you looked at the P::C source? :]
No, but I know where I put my own and why.
Having to put "no critic" on something genuinely weird is fine. These are the
valid critics in MakeMaker that I individually hushed with specific reasons.
./lib/ExtUtils/MakeMaker.pm:sub prompt ($;$) { ## no critic
./lib/ExtUtils/MM.pm:eval "require $class" unless $INC{"ExtUtils/MM_$OS.pm"};
## no critic
./lib/ExtUtils/MM_Unix.pm: if( open(STDERR_COPY, '>&STDERR') ) { ## no
critic
./lib/ExtUtils/MM_Unix.pm: open STDERR, ">&STDERR_COPY" ## no
critic
./lib/ExtUtils/MM_Unix.pm: $result = eval($eval); ## no critic
./lib/ExtUtils/MM_VMS.pm: %xs = map { s/.xs$//; ($_,1) } glob('*.xs');
## no critic
I agree with perlcritic, I am breaking good programming practice, and I'm fine
with having to think about and note the exceptions.
perlcritic found a bunch more weird things that I instead altered to conform
with perlcritic's recommendations. They were good recommendations. This is
why I'm so adamant that perlcritic not consider expert programmers exceptional.
Show quoted text>> Besides, it's not like PBP hasn't been wrong before. It's not some
>> set of stone tablets from God to Damian to Perl::Critic.
>
> As he says in the introduction in the book. P::C's role is to enable you to enforce the
> set of rules that you agree with.
Ahh, but somebody has to choose the defaults and the rules. And presumably
they put some thought into that.
The better it works out of the box the better chance someone will use it.
When you're already skeptical about the value of a tool, being told you have
to spend a bunch of time tweaking tends to just fuel that skepticism.
Show quoted text>> I see perlcritic doesn't ding me for my use of floating point
>> $VERSION despite 17.3 clearly stating "Don't use floating-point
>> version numbers."
>
> No, it doesn't. Yet. Care to contribute one that does?
Even Damian doesn't think that's a good idea anymore. I'm more than a little
horrified because it implies that Perl::Critic *is* blindly following PBP!
The solution is worse than the problem. version.pm introduces all sorts of
fascinating complications, much worse than the odd floating point error. This
is a spot where I can say I probably know more about it than Damian, although
perhaps not after he published PBP and got all the fun feedback about that
particular recommendation.
I have just two requirements for a version number:
1) It compares as a number and without warnings.
2) It only goes up over time.
These days I'm recommending integer version numbers, but X.YYY is still fine.
http://use.perl.org/~schwern/journal/35127
There is one part of the PBP version discussion that I would enforce: Don't
use vstrings.
I'd add in another, that $VERSION should not be /^\d\.\d$/; That is, just one
decimal point. This strongly implies that the user expects 1.2 < 1.11.
A final critic is if $VERSION is a number (not a string) and /0$/ as in 1.10.
The trailing zero will be lost. It's possible it might be handy to recommend
all simple decimal versions be strings.
Show quoted text> Let's turn this question around. Are there any places where you personally
> would like this policy to complain?
Not personally, no, I haven't run into this yet in my own code and never run
into anyone who got confused.
Like I said I can accept the idea that in the general case bare octal numbers
may be used incorrectly by a beginner. I've never run into it myself, but I'm
willing to defer to Damian's wider newbie teaching experience. As the policy
is more than a bit speculative, and the mistake quickly revealed, I wouldn't
put it at the highest severity.
Compare with, say, the policy against 2 arg open. That's a clear security
hole and thus perlcritic can say, with good certainty, that 2 arg open is a
bad idea. It's also the sort of thing that, if it's never explained to you,
you probably never would have known it's a problem. I didn't know until
yesterday.
As opposed to the notion that 0123 == 123. A notion that won't last very long
if you actually try to apply it.
--
THIS I COMMAND!
