in reply to Re^3: Burned by precedence rules (== true)
in thread Burned by precedence rules

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

Replies are listed 'Best First'.
Re^5: Burned by precedence rules (fail() if "false";)
by tye (Sage) on Dec 28, 2008 at 21:06 UTC

    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        

[reply]

      I have often said that I have learned as much from the really bad code that I have maintained as I have from the really good code I have maintained. (That applies to both my code and other people's code.)

      If a value of FALSE that is not false doesn't scare you enough, I won't tell you what I found FOUR defined as...<grin/>

      G. Wade
[reply]
[d/l]
[select]

        I still have to say that my favorite maintenance horror is the block that had (including comments) the $language equivalent of 

        $x = 1;
$x = 1;   # Just to be sure

        [download]

        *shudder*

        --MidLifeXis

[reply]
[d/l]

        No doubt it was originally defined as FOUR = 4, but then somebody was told to change it to 42 or π. This is why I tend to avoid setting constants like THREE = 3. I find it rather annoying to have constants with clear names that lie. After all, complex code is self-obfuscating; it doesn't need any help.

        Information about American English usage here and here. Floating point issues? Please read this before posting. — emc

[reply]

In Section Meditations