macOS Share your Cocoa naming schemes

It's usually more important to know what a certain variable represents, rather than what type it is. I would call it something like


I notice that in the Objective-C world, it's not custom to distinguish member variables from nonmember variables, which is common practice in C++. I find myself doing that anyway, so it would be


in my programs.

I used to prefix my ivars with _ but Apple says to not do that since it's reserved for their private use, and I've actually run into problems with this (where I define a variable that's already a private var in a superclass). Then for a short while I used the m prefix, but recently I've stopped using prefixes altogether. I read an article that said it's basically pointless to use prefixes because if you are, then that might mean your class is getting too large to easily determine whether a variable is an ivar, global, or local, and so at that point you should be looking at refactoring. Anyways, that is not always the case for everything, but I think it holds true for the majority of cases. So I've stopped using prefixes and try to name things clearer. For example with a text field I might use nameField, or for a button okButton. If it's a class with few controls I just use textField, tableView, etc.

Also I dislike extensive use of variables that are acronyms for something that only the original developer knows unless you spend 30 minutes examining the code. A project I'm working on has this all over the place and it drives me a bit mad at times

kainjow said:

I used to prefix my ivars with _ but Apple says to not do that since it's reserved for their private use, and I've actually run into problems with this (where I define a variable that's already a private var in a superclass). Then for a short while I used the m prefix, but recently I've stopped using prefixes altogether. I read an article that said it's basically pointless to use prefixes because if you are, then that might mean your class is getting too large to easily determine whether a variable is an ivar, global, or local, and so at that point you should be looking at refactoring. Anyways, that is not always the case for everything, but I think it holds true for the majority of cases.

Click to expand...

Thanks for that little insight...that's why I like listening to the experts!!

GorillaPaws said:

How would you handle the naming of the contents of that variable once it got passed into the model?

Any thoughts on people coming up with personal unique 2 letter prefixes to prevent collisions with either 3rd party frameworks or Apple's code? Also, I haven't heard of people using suffixes before, is there a general reason why "nameField_" wouldn't be an appropriate compromise to not stepping on Apple's toes?

Click to expand...

Hi

For C++ I do just what you say, ie use a trailing _ for class variables. I tried other schemes but settled on this one. I don't think it clashes with anything.

b e n

The "trailing underscore" scheme is often used in C++. I don't particularly like it myself, but that's entirely a matter of taste.

As to underscore prefixes, the official rule is that any symbol starting with two underscores is reserved for the platform, as are symbols starting with a single underscore followed by a capital letter.

The reason I like prefixes for members ("ivars" in Objective-C speak) is for understanding what a certain piece of code does when I later look at a function; I typically "backtrace" to figure out where a certain variable came from, and when I don't see any declaration in the code nor in the function parameters, I get confused. Again, that could be just me. It's also a matter of how advanced your IDE is; if it would indicate member/local/parameter/global (ugh) when you hover over a variable, there would be no need for prefixing.

I prefix my locals with "in" or "out". But only in when there is a naming conflict in methods that need to use both the local and instance, like a setter.