Skip to main content
Software Engineering

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

8
  • 1
    +1 for this being the one answer with the actual useful technical explanation. Commented Feb 26, 2012 at 10:19
  • I still think this way, regardless of programming language I always assume that == true is unsafe. Feels better that way. Commented Feb 26, 2012 at 12:06
  • 1
    @Dervall: assuming something that's simply not the case is also no good. There are a few corner cases in certain languages where equality comparison of booleans is not only safe but in fact appropriate, for instance in Haskell, which has a strong implicit-cast-free type system with bidirectional type inference, one might write (==True) . f to clarify that we want the -> Bool instantiation of the return-polymorphic function f. That's clearer than not . not . f and less awkward than (f :: a -> Bool). Commented Feb 27, 2012 at 12:48
  • 1
    @leftaroundabout: That's fine if you know that pred(x) and pred(y) use the same value to denote truth, which is a safe assumption in some languages but not in others. In C, for example, you might write !!pred(x) == !!pred(y). Commented Feb 27, 2012 at 18:36
  • 2
    @KRyan: Equality comparison to false happens to be "safe", since 0 is the only "false" value -- but it's IMHO better to avoid equality comparison to either true or false in general. Commented Nov 30, 2015 at 21:59