I've actually used:

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

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
   || ...
   || ...
   || ...
) {
  ...
}
[download]

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.

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.

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.

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";
}
[download]

under `perl -MO=Deparse test.pl`, produces:

test.pl syntax OK
$x = 3;
if ($x == 2 or $x == 3) {
    print "Yeah!\n";
}
[download]

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

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

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

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.