Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re: Pearls (not really) of Perl programming

by cosimo (Hermit)
on Nov 24, 2004 at 17:36 UTC ( #410190=note: print w/ replies, xml ) Need Help??


in reply to Pearls (not really) of Perl programming

Another one, from the obscure deepness of perl realms (whatever this may mean)...

my @where = ("item='$item'", "location='$location'", ... ); my $cSql; foreach( @where ) { $cSql .= ' ' . $_ . ' AND'; } chop $cSql; chop $cSql; chop $cSql;
In our team, this is called the famous Triple Chop Technique.
Probably it should be considered a kind of negative pattern.


Comment on Re: Pearls (not really) of Perl programming
Download Code
Re^2: Pearls (not really) of Perl programming
by ikegami (Pope) on Nov 24, 2004 at 19:37 UTC

    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.

      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.

      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.
      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 "||".

      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... ;-)

Re^2: Pearls (not really) of Perl programming
by Jenda (Abbot) on Nov 30, 2004 at 00:01 UTC

    Might be negative pattern in Perl with its join() and map() builtins, but assuming you happen to be forced to write code is a language that doesn't provide anything similar ... I use something like this quite often actually when "working" in VBScript. Better than trying to make sure you do not put the separator before the first item or after the last one. Recently had a problem with some code that tried that. And failed miserably because it did not take into account that the joined values could be empty.

    Jenda
    We'd like to help you learn to help yourself
    Look around you, all you see are sympathetic eyes
    Stroll around the grounds until you feel at home
       -- P. Simon in Mrs. Robinson

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://410190]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (16)
As of 2014-10-30 19:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (208 votes), past polls