macOS Share your Cocoa naming schemes

[GorillaPaws]

I just wanted to start a thread for people to discuss and share the systems/conventions they use for naming their objects/variables/methods etc. I'm assuming that everyone follows the standard guidelines but I'm wondering about the various strategies that people use for naming.

Things like:

IBOutlet NSTextField *textField;

don't sit well with me. I feel like there should be something in the name of that instance of NSTextField to indicate what it's role is. But then it seems like it's easy to start getting ridiculously long variable names. When your app is simple and only has one NSTextField, it's purpose is fairly obvious, but as your GUI evolves it's certainly possible that you may have more NSTextField instances and calling them textField1, textField2 etc. doesn't really seem appropriate either.

I'm still a novice and haven't developed a style, so I'd be interested to see some of the strategies you guys use so I don't stumble into bad habits early on. Thanks in advance for any wisdom you pass on.

 

[Sander]

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

IBOutlet NSTextField* name;

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

IBOutlet NSTextField* m_name;

in my programs.

 

[kainjow]

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

 

[mdeh]

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.

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

 

[GorillaPaws]

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

IBOutlet NSTextField* name;

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?

 

[lazydog]

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?

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

 

[Sander]

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.

 

[WhiteRabbit]

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.