[efnx]

That's not bad code, you must be sarcastic. I've never heard of the method isDifferentFromString: and besides, the method name suggests it's the same thing as isEqualToString: approached from the other side. Are you referring to the capitalization mistake in @"steve"? When using sarcasm keep in mind there's no tone in text ;)

[alayne]

He's not being sarcastic. Maybe a better example of what he is trying to get at is

if (![missleLauncher isDisabled]) { /* declare thermonuclear war */ }

When missleLauncher is nil, thermonuclear war is still declared which may not be the programmer's intent.

[xsmasher]

Properties and methods are given "positive" names as a matter of convention, and to make reasoning about Nil easier.

In Objective-C, the question "should I name my method isEnabled or isDisabled?" has a reasonable answer - you consider what makes most sense (or any sense) when called on Nil.

This is probably a good rule for other languages too - "negative" booleans can lead to double-negatives and unreadable code.

[alayne]

Even with a positive naming convention, you will have conditionals for the negative case, e.g. if (![str isEqualToString:@"myvalue"]) and falling into its block is not desirable when str is nil. Personally I have had plenty of bugs around things being unexpectedly nil, but I can't think of a case like this where I executed a block unexpectedly.

[optymizer]

<sarcasm>Well, if you've never heard of it then it cannot exist and that invalidates his example, right? </sarcasm>

I'm not saying the example is correct, I'm pointing out that "I've never heard of it" / "Works on my computer" are dangerous attitudes to have.

[efnx]

I'm sorry, I should have been more clear. I meant "I've never heard of that method, so I looked it up in Xcode and it turns out it is not a method on NSString (and why should it be if !isEqualToString: achieves the same purpose?) which leads me to believe that this comment is sarcasm, if it isn't can you please clarify?"