Pathologically Eclectic Rubbish Lister | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
I would urge you not to define constants for TRUE and FALSE when the language doesn't provide them. One of the nastiest bugs I ever had to track down was caused by someone defining these constants slightly differently than the way the language did. We were constantly surprised when !$is_bad, FALSE == $is_bad, and TRUE != $is_bad did not give the same answers. My favorite readability move for code like this would be to rename the methods (maybe is_done) to work better in conditionals. In your example, I have a bigger problem understanding why foo returning a true value means that we are not done. If, on the other hand, the method were named is_foo_running it would be easier to understand. Although I have fought the no magic literals fight for years, true and false are not where I prefer to fight.
G. Wade
In reply to Re^2: Burned by precedence rules
by gwadej
|
|