Лично я долго пользовался последним выражением, но поменял местами. Использование "foo == nil" (или nil == foo, чтобы избежать ошибок, вызванных забыванием одного '=') более педантично. Со временем вы устанете набирать его, и первая версия также неуязвима для случайной ошибки назначения нуля.
Хорошо для новых кодеров быть многословным в том, что они кодируют, так как это дает им возможность заставлять их задумываться о том, что на самом деле происходит, но позже, конечно, переключается на версию, которая быстрее, если она эквивалентна.
Если по какой-то безумной причине nil-указатели больше не были 0, а имели какое-то другое недопустимое значение (есть целые гигантские области памяти, которые недопустимы в качестве указателей), тогда используйте '!' больше не будет работать, но этого никогда не произойдет (или если это произойдет, они добавят поддержку компилятору для перегрузки '!', чтобы это означало "недопустимый" при использовании с указателем объекта и делали правильные вещи во всяком случае, иначе разработчики Objective-C в мире сошли бы с ума).
Единственная тонкая проблема с этим состоит в том, что он может начать учить вас путать значение логических выражений C со значениями других типов, что не является тем же. Итак, если вы начинаете думать, что логическое выражение - это просто BOOL, скажем, вы можете предположить, что присвоение ненулевого значения переменной BOOL будет делать то, что вы хотите, но не будет. Поскольку BOOL - это просто символ (на данный момент), если вы делаете что-то вроде:
- (BOOL)checkFoo {
BOOL foo = [bar count]; // imagine count is > 255
if(foo)
[self doSomething];
return foo;
}
, где неявное приведение 256 или выше к BOOL дает вам ноль (НЕТ) путем усечения, а не ДА, что вам нужно, по сравнению с
- (BOOL)checkFoo {
BOOL foo = ([bar count] > 0);
if(foo)
[self doSomething];
return foo;
}
или
- (BOOL)checkFoo {
if([bar count]) {
[self doSomething];
return YES;
}
return NO;
}
Все, что я говорю, убедитесь, что вы понимаете фон и тонкости.