Sure, it makes some edge cases harder to debug, but not by very much.
One of the edge cases that I've recently seen in some code is string comparison:
if ([myStr caseInsensitiveCompare:@"OtherString"] == NSOrderedSame)
{
// Do something
}
If myStr is nil, caseInsensitiveCompare is going to return nil (=> 0), which is the same as NSOrderedSame. In these cases, you either have to check for nil first or swap the variables:
if ([@"OtherString" caseInsensitiveCompare:myStr] == NSOrderedSame)
{
// Do something
}
True, that's actually quite a tricky bug. However, that's also a flaw in Cocoa, I think. NSOrderedSame should not evaluate to a falsy value. Rather, the enum should start at 1.
Comments
Sure, it makes some edge cases harder to debug, but not by very much.
One of the edge cases that I've recently seen in some code is string comparison:
If myStr is nil, caseInsensitiveCompare is going to return nil (=> 0), which is the same as NSOrderedSame. In these cases, you either have to check for nil first or swap the variables:True, that's actually quite a tricky bug. However, that's also a flaw in Cocoa, I think. NSOrderedSame should not evaluate to a falsy value. Rather, the enum should start at 1.
Agreed. I think the reason it starts at -1 is to make sorting easier.
I usually use a category for string comparison so I don't have to think about it.