Quindi personalmente odio davvero NSNotFound
ma capisco la sua necessità.
Ma alcune persone potrebbero non comprendere la complessità del confronto con NSNotFound
Ad esempio, questo codice:
- (BOOL)doesString:(NSString*)string containString:(NSString*)otherString {
if([string rangeOfString:otherString].location != NSNotFound)
return YES;
else
return NO;
}
ha i suoi problemi:
1) Ovviamente se otherString = nil
questo codice andrà in crash. un semplice test sarebbe:
NSLog(@"does string contain string - %@", [self doesString:@"hey" containString:nil] ? @"YES": @"NO");
risultati in !! CRASH !!
2) Ciò che non è così ovvio per qualcuno che non conosce Object-C è che lo stesso codice NON si bloccherà quando string = nil
. Ad esempio, questo codice:
NSLog(@"does string contain string - %@", [self doesString:nil containString:@"hey"] ? @"YES": @"NO");
e questo codice:
NSLog(@"does string contain string - %@", [self doesString:nil containString:nil] ? @"YES": @"NO");
comporterà entrambi
does string contains string - YES
Che chiaramente NON è quello che vuoi.
Quindi la soluzione migliore che credo funzioni è usare il fatto che rangeOfString restituisce la lunghezza di 0, quindi un codice migliore e più affidabile è questo:
- (BOOL)doesString:(NSString*)string containString:(NSString*)otherString {
if(otherString && [string rangeOfString:otherString].length)
return YES;
else
return NO;
}
O SEMPLICEMENTE:
- (BOOL)doesString:(NSString*)string containString:(NSString*)otherString {
return (otherString && [string rangeOfString:otherString].length);
}
che verrà restituito per i casi 1 e 2
does string contains string - NO
Sono i miei 2 centesimi ;-)
Controlla il mio Gist per un codice più utile.