Enum defining forms in Objective-C

enum is as old as C, therefore a part of Objective-C.It is just explicit coding of an int type. It's quite useful for debugging and most newer compilers can make optimizations based on it. (Which you should totally ignore). It's most useful in making your code more readable (to anyone else, or to yourself after you've slept).

typedef enum {    ...} NameType ;

would be followed by

NameType name;

and that's typically the preferred style of a typedef,

your second example will not tie the typedef to the values you want to specify should only be of the given type.

Note that this does not prevent you from executing

name = 10244; // some non-valid value not listed in the enumeration

but some compilers might generate a warning in that case,

I ran across Apple's use of the following today:

enum {NSFetchedResultsChangeInsert = 1,NSFetchedResultsChangeDelete = 2,NSFetchedResultsChangeMove = 3,NSFetchedResultsChangeUpdate = 4};typedef NSUInteger NSFetchedResultsChangeType;

They do this because they really want the NSFetchedResultsChangeType to be of the type they have defined as NSUInteger. This can be an int but it can also be something else. And with values of 1, 2, 3, and 4, it's somewhat irrelevant to us what the type is. But they are coding to a different level of abstraction because they are a tools provider.

You should never look to Apple for coding style hints. If you see something that looks like it's cleaner/better way to code, it usually is. As Kevin mentioned, API stability is of paramount importance for them.

Edit (Jan 2013) If you have access to the WWDC 2012 Session Videos, you should watch Session 405 - Modern Objective-C 6:00-10:00. There is discussion a new syntax in the newer compiler that allows explicit sizing of a type and tight bonding of values to types. (borrowed from C++ 11)

enum NSFetchedResultsChangeType : NSUInteger {NSFetchedResultsChangeInsert = 1,NSFetchedResultsChangeDelete = 2,NSFetchedResultsChangeMove = 3,NSFetchedResultsChangeUpdate = 4};

The former defines a type name to refer to an enum. This is the way most enums are named in C. The latter is a bit different though, and it's prevalent in the Cocoa frameworks. There's two reasons to use the latter. The first is if your enum defines a bitfield, and you'd want it here because when you're providing a "Name" value you'll be providing a combination of the enum values. In other words, if you say something like

[self doSomethingWithBitfield:(Enum1 | Enum2)]

you're not passing a value of Name but rather an integer that's a combination of the two.

However, Cocoa frameworks use this idiom even for non-bitfield values, for a very good reason: API stability. According to the C standard, the underlying integral type of an enum is requires to be able to contain all values in the enum, but is otherwise chosen by the compiler. This means that adding a new enum value could change the integral type of the enum (e.g. adding -1 can make it signed, adding 6 billion can make it into a long long, etc). This is a bad thing from an API stability standpoint, because the type encoding of methods which take values of this enum could change unexpectedly and potentially break existing code and binaries. In order to prevent this, the Cocoa frameworks generally define the type as being an NSUInteger (or NSInteger if they need negative numbers), so the API and type encodings stay stable.