Re^5: Burned by precedence rules (fail() if "false";)

[tye]

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

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.

[gwadej]

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/>

[MidLifeXis]

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

*shudder*

[Anonymous Monk]

Some folks (i'm talking about you MidLifeXis) just don't understand humor :)

[swampyankee]

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.

[gwadej]

Something like that.

This is why I started using the term magic constants a few years ago to complement magic literals. Everybody agrees that magic literals in code are a bad idea. But, what happens when the constant you chose to replace is with provides no more meaning or abstraction...magic constant.

A constant like FOUR provides so little information that it would have been better to leave the original literal 4 in the code.