Peter Steinberger

@steipete well I prefer not to check it at all. There is nothing valuable in this check.

@daloog It’s convention and you’re in trouble if you don’t do that for class clusters or other special types.

@steipete sure. There is cases when check is required be design. But general NSObject inheritance is 99% of my code. So I can skip it.

@daloog @steipete The check is only required if you access ivars directly after. If you only send messages, nil return is fine.

@mpweiher @daloog … which is what you should to in init and dealloc. Properties can have side effects -> bad. Especially when designing API.

@steipete @daloog My practice is to always have base props w/o side effects. Seems pretty common these days.

@mpweiher @DAlooG fair enough. We can't rely on that in our SDK as people might subclass.

@steipete I like one the one line version, but with double (( as you've shown, even though it's not required by clang.

@nicklockwood Oh there’s a warning for that, we run with -Weverything minus a few extremes.

@steipete me too!

@steipete self=[super init]; Then use accessors to set ivars. No if.

@mpweiher @steipete and what if [super init] returns nil?

@nicklockwood @steipete Messages are ignored and you return nil. Perfect! (Also: usually, a [super init] nil return is non-recoverable)

@mpweiher @steipete ivar accesses aren't messages. Writing _foo = bar Is equivalent to self->_foo =bar Which will crash if self is nil.

@nicklockwood @steipete Exactly. Which is why you don’t do ivar accesses but —> send messages <—

@nicklockwood @steipete Apple’s recommendation to use direct ivar access in -init is mostly BS.

@mpweiher @steipete ah, I missed the part of your suggestion to use accessors in init. That makes sense.