The compiler's good with array.count and array.firstObject, etc. I am too. Can we be? about objective-c-style-guide HOT 11 CLOSED

The compiler is also fine with:

id <UIApplicationDelegate> appDelegate = UIApplication.sharedApplication.delegate;

but I'm pretty sure none of us would advocate that this style as a way to get the app delegate.

from objective-c-style-guide.

I'm going to start using that!

from objective-c-style-guide.

@paulbruneau the reason the compiler complains is because you are not assigning the result of the removeAllObjects method call to anything - in fact, you can't, since it's a void method. In Matt's example, he's using the result of the method, hence no compiler complaints.

from objective-c-style-guide.

If Apple wanted it to complain about myArray.count, surely it could. They apparently don't, and it doesn't.

from objective-c-style-guide.

If Apple had the compiler complain about every violation of how a construct is intended to be used, we wouldn't need a style guide.

from objective-c-style-guide.

No one said that, Straw Man. The decision is ours, I'm just providing some evidence to back my desire to not have to remember to put brackets around -count.

from objective-c-style-guide.

I also really like Brent's thoughts on this one because he mentions the problem of finding things later.

from objective-c-style-guide.

I believe the compiler warning @paulbruneau points out can actually provide some guidance about the intentions behind properties and when dot-notation for calling a method is appropriate.

If an operation is idempotent and has no side effects—by which I mean there are no visible modifications to state, either the receiver's or in any other object's—then property notation ought to be acceptable, particularly for trivial cases such as count and length.

I further assert that this usage, like proper usage of the ternary operator, "increases clarity [and] code neatness". It certainly hurts neither of those properties, and I believe it can help clarify the programmer's intention.

id <UIApplicationDelegate> appDelegate = UIApplication.sharedApplication.delegate;

Certainly, like anything else, this construct can be abused to create legal but unclear and unreadable code, and such usage should be prohibited.

I also really like Brent's thoughts on this one because he mentions the problem of finding things later.

I am simply not convinced this is enough of a problem to worry about. But setting that aside, I don't believe the argument applies here. Given my proposed usage rules, let's consider searching for the code that gets the managedObjectContext from a managed object. This method call could look like: object.managedObjectContext or [object managedObjectContext], but a search for managedObjectContext will find either usage.

If Apple had the compiler complain about every violation of how a construct is intended to be used, we wouldn't need a style guide.

You can make clang complain about a lot of violations of intended use :)

(Note that my definition of "side effect" is not "does something other than read an ivar", it's "a function or expression is said to have a side effect if, in addition to returning a value, it also modifies some state or has an observable interaction with calling functions of the outside world.", per http://en.wikipedia.org/wiki/Side_effect_(computer_science) )

from objective-c-style-guide.

These are all properties in iOS 8, so this isn't needed any longer.

from objective-c-style-guide.

I was right! Yay!

from objective-c-style-guide.

I was right! Yay!

:D

from objective-c-style-guide.