I disagree.

The problem is not in defining 'true' and 'false' constants other than ones predefined by the language. The real problem is using any such Boolean constants in (in)equality expressions.

One should never write anything like "== false" and one should rewrite any such code that one runs into (when practical). For one thing, it is needless complex, even redundant.

Yes, defining 'true' and 'false' constants exacerbates this problem and the problem is somewhat mitigated when a language has a first-class Boolean data type (that can't be made to hold other than the two special values) -- which also means that the language likely defines its own symbolic representations for those two special values.

But one can certainly sanely use 'true' and 'false' constants even in Perl. Just don't test for equality against Boolean values, especially against Boolean constants. And one should follow this practice even in languages where a real Boolean datatype mitigates the seriousness of such redundant constructs.

I'm sure i shouldnt say this, but more than once I have written

if ( !$x == !$y ) { ... }
if ( !$x != !$y ) { ... }
[download]

which I think is a fair exception to your rule. I kinda view ! and !! as "boolean constructors", and so long as both sides of your (in)equality are guaranteed to be a "boolean" obtained one of these constructors you can compare them.

But I'm really just nit-picking. :-)

---
$world=~s/war/peace/g

There's a logical operator for that: xor

if ( !$x == !$y) ) # bool($x) == bool($y)
if ( !$x != !$y  ) # bool($x) != bool($y)
[download]

can be written as

if ( !($x xor $y) ) # bool($x) == bool($y)
if (   $x xor $y  ) # bool($x) != bool($y)
[download]

Unforunately, both sets have readability issues.

Even outlawing comparisons to the constants isn't enough.

sub is_tested {
    return FALSE;
}
[download]

and then used as

  if( is_tested() ) {
     print "is tested.\n";
  }
[download]

and, by the way, FALSE is defined to be 2. This was the sort of thing that haunted me for days.

I was using those expressions to describe the problem not the usage.

G. Wade

Wow, defining your FALSE constant to a value that isn't actually false is such an amazingly bad idea that I never even considered it. Yes, don't define Boolean constants that completely defy your language's concept of "true" or "false". Duh! :) Thanks for mentioning that.

- tye        

I had exactly the same thought on the sub name and "false means true" issues, but thought I'd leave it alone for the moment. I do think the use of constants in one form or another is a valid approach, but you need to make sure it's used consistently throughout the entire project. That can be a challenge.