Firstly, it’s more code for no good reason. Even if it’s just one more line, It’s one more line to debug and test. It’s one more place where something could go wrong.

Secondly, it’s not idiomatic Cocoa-code, so it signals that something strange is going on. That’s a problem for whoever is reading the code, because they have to stop and look around more carefully to figure out why the pointless tests are happening.

The baseImage = nil is also redundant. If dealloc is getting called, the memory holding that pointer is about to be released anyway. The only way I can imagine that would prevent a dereference into freed memory is if super’s dealloc somehow references that ivar (a sign of bad architecture) or there’s some horrible threading issue. You’d want it crashing in those cases to let you know something bad is happening.

You’re right Dave. But I very strongly believe in keeping a contract with my ivars that either they are nil, or point to a valid object. In fact, I’d go so far as to say that it’s easier to habitually do redundant = nil; assignments than to ever think about when they’re redundant. This is easier to do with @properties, because self.baseImage = nil; does both in one statement.

Also, there is a not-quite-best-practice-but-not-pathological case where niling out freed ivars saves your bacon. Say you override some of your setters to do [self.someOtherObject noteChanges]; whenever their value changes. If you don’t set someOtherObject to nil when you release it, then you have to be very careful about the order you set things to nil, or you have to directly release your ivars. This adds complexity and failure points that don’t exist if someOtherObject is defined to always to be a message-able variable.