2 ms·
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
by Aqua_Geek 15y ago
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
}
- SeoxyS 15y agoTrue, 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.
- Aqua_Geek 15y agoAgreed. 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.