the hazards of coding for webservers vs. shell scripts

[kareila]

When I was doing some code cleanup a few months ago, I saw some lines that looked like this:

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: exor674 says this command will find it (but not in BML files):

perlcritic --single-policy ProhibitConditionalDeclarations

Comments

[thorfinn]

I actually highly recommend adopting perlcritic must pass with no warnings (as a simpler to validate version of "must obey all of the rules in Damian Conway's Perl Best Practices book") and perltidy with Damian Conway's .perltidyrc outright as enforced checkin on Perl code.

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.