Entry tags:
the hazards of coding for webservers vs. shell scripts
When I was doing some code cleanup a few months ago, I saw some lines that looked like this:
I decided that looked redundant and changed it to:
Take my advice: don't combine "my" statements and postfix conditionals. Ever.
I've updated the programming guidelines to warn people away from this as well.
The manifestation of this particular bug was to cause the $foo variable to be referenced in global scope if the conditional was false. In that situation, the assigned value would persist across execution threads, such that if two people in a row had a true $baz, the second user would see the first user's value of $foo. Even with use warnings and use strict in effect, Perl apparently thinks this is perfectly fine.
ETA:
exor674 says this command will find it (but not in BML files):
my $foo;
$foo = $bar unless $baz;
I decided that looked redundant and changed it to:
my $foo = $bar unless $baz;
Take my advice: don't combine "my" statements and postfix conditionals. Ever.
I've updated the programming guidelines to warn people away from this as well.
The manifestation of this particular bug was to cause the $foo variable to be referenced in global scope if the conditional was false. In that situation, the assigned value would persist across execution threads, such that if two people in a row had a true $baz, the second user would see the first user's value of $foo. Even with use warnings and use strict in effect, Perl apparently thinks this is perfectly fine.
ETA:
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
perlcritic --single-policy ProhibitConditionalDeclarations
no subject
my $foo = $baz ? $woo : $bar;
no subject
no subject
my
isn't conditional.It's the difference between:
And
no subject
I never realized it actually causes problems like this, though!
no subject
no subject
The sort of pathological case we need to prevent looks like this:
my $foo = $bar unless $baz;
# stuff that uses $foo without checking $baz
no subject
perlcritic --single-policy ProhibitConditionalDeclarations cgi-bin/*
(or any other directory you wanna run over)
no subject
Conway's Perl Best Practices' general reaction to postfix conditionals in any circumstance is STAB STAB STABBITY STAB, which is why perlcritic can be set to warn against them, but I know this is direct opposition to our coding guidelines.
no subject
no subject
no subject
unless
at all, as my brain prefers consistency; I can deal with negatedif
s.But of course I stick to the coding guidelines for DW.
no subject
Good to know though. I'm somewhat surprised that it persists across threads though.
no subject
no subject
There are entirely good reasons to avoid some of the rules in perlcritic, yes. The thing is, it is a whole lot simpler and easier to accept the Conway Perl::Critic ruleset wholesale, than it is to try and go around making individual exceptions.
It's almost certainly not worth going around and changing the entire existing codebase, but it is something that can be done on new checkins.
Alternately, it's possible to set up a .perlcriticrc and .perltidyrc to suit the DW coding standard, and then pass that around.
Perltidy in particular saves a lot of manual inspection for formatting standards and Perl::Critic similarly for coding style standards, especially if you turn on the option that prints the explanation from the book for any rule failures.
no subject