http://www.perlmonks.org?node_id=410229


in reply to Re: Pearls (not really) of Perl programming
in thread Pearls (not really) of Perl programming

I've actually used:

$sql = '... WHERE 1=1'; $sql .= ' AND ...' if (...); $sql .= ' AND ...' if (...); $sql .= ' AND ...' if (...);

In defense, 1) it wasn't in Perl, which has the convenient join function, and 2) the conditions where not already in an array as in the above snippet.

For the following, though, I deserve to be shot:

if (0 || ... || ... || ... ) { ... }

I do it just so all the conditions line up nicely.

Update: That should be WHERE 1=1 (not WHERE 1) because 1 does not mean true in SQL, or at least not for the database I was using.

Replies are listed 'Best First'.
Re^3: Pearls (not really) of Perl programming
by dimar (Curate) on Nov 24, 2004 at 22:30 UTC

    I am very glad that ikegami posted this, because this touches on something of a pet peeve. This should be considered by anyone who has ever added a noop to code for the mere sake of symmetry.

    Considering that ikegami is someone who knows his stuff ... the (tongue-in-cheek) "deserves to be shot" remark is well taken, but also a bit discouraging because of a common tendency out there ... what is that tendency?

    Programmers tend to unfairly critique (and even bully) themselves (and others) when they don't take the time to distinguish anomolies that arise from ignorance, from anomolies that arise from a justifiable desire to do things differently.

    Who knows how it got started, perhaps when we were small children and told to "color inside the lines" of our coloring book ... but dammit ... what if the lines are in the wrong place to begin with? The mere fact that many many (experienced) people have done this kind of 'coding faux pas' indicates to me that there is some merit to this 'anti-pattern', and we should think twice before poking fun or shooting at ourselves when we use it.

    This is not to detract from ikegami's point, but rather a tangent, in hopes that we don't stifle our own creativity in our attempts to do 'what is expected of us'.

    Sometimes you just gotta color outside the lines.

      I agree. I don't have a problem with coding however you want, even if that vast majority of the world considers it to be wrong. The important thing is that you have sound reasons for doing it that way (ie. the lines really are in the wrong place), that you understand those reasons, and preferably document them.
Re^3: Pearls (not really) of Perl programming
by itub (Priest) on Nov 24, 2004 at 20:02 UTC
    Hey, I've done that! ;-) But let me explain: it was a quick and dirty way of forcing the if to go one particular way during debugging. The zero is a no-op, but you can then easily turn it into a 1 when you want to force the condition to be true. I don't think it is much worse than commenting out some code.
Re^3: Pearls (not really) of Perl programming
by bart (Canon) on Nov 25, 2004 at 11:57 UTC
    It's not that bad, at least in perl, as it appears to optimize it away. At least, on ActivePerl 5.8.4, the following script:
    #! perl $x = 3; if(0 || $x == 2 || $x == 3) { print "Yeah!\n"; }
    under `perl -MO=Deparse test.pl`, produces:
    test.pl syntax OK $x = 3; if ($x == 2 or $x == 3) { print "Yeah!\n"; }

    In general, I prefer my "||" on the right:

    $x = 3; if( $x == 2 || $x == 3) { print "Yeah!\n"; }

    If you want, you can still append "|| 0" to the condition, allowing for more symmetry, but not optimized away. At least it'll only be executed if every other condition fails.

    There's a reason why Perl accepts lists ending with ",", or at least: it's a good thing Perl accepts lists ending with ",". In a way it's too bad (tough understandable) it won't do the same for "||".

Re^3: Pearls (not really) of Perl programming
by cosimo (Hermit) on Nov 25, 2004 at 12:33 UTC

    Ah!

    After reading it three or four times, I suddenly realized now that the other conditions where OR'ed, not AND'ed! Beautiful (++)! I thought that you used the Zeroing Technique™ to automatically determine boolean value of whole expression (0 or 1).

    And the nicest thing is that my mind shifted towards that interpretation because I actually used it somewhere... ;-)