I’m annotating an Objective-C framework for nullability to improve the interaction of the framework with Swift code. Annotating Objective-C code as I have found has helped a little to clarify my thinking.

I have religiously kept to the following pattern where I always check the return value of [super init]:

@interface Timer : NSObject
@property (assign) startTime;  

@implementation Timer  
  self = [super init];

  if (self)    
    self->_startTime = start;
  return self;

Now I question myself as to why am I checking whether self is nil here, because I’ve been reviewing Objective-C code for annotation for nullability.

There is no need to be checking for nil here, if [super init] returns nil when super refers to a NSObject object the program is going to crash in the very near future anyway.

I think sometime ago I was guided to follow this pattern always so that if I was to change the class that Timer inherits from then the pattern keeps you safe from potential changes in behaviour. Somewhere along the line I forgot this and this just became a pattern I followed.

The consequence now is that when annotating for nullability I’ve got to break the anxiety* that this causes me where I have to accept these checks for nil in many cases do nothing and I have to look beyond this test to determine if initialiser will return nil.

*Cognitive dissonance like this creates a strange anxiety for me that brings work to a halt. The writing of this blog post is the action that breaks the connection.