views:

126

answers:

4

What's your preference with naming ObjC classes? I'm a little uncertain what would be the most reasonable approach on this so it would be nice to hear some other opinions.

Apple recommends prefixing cocoa classes, because ObjC doesn't support namespaces. The Google ObjC styleguide (which i mostly aim for) does away with them, unless you're extending (category, class extension etc.) a NSClass.

My preference would be NOT to prefix classes, because i also think it's a waste of letters and doesn't contribute to a cause. It should only be used in framework code to signal that this class belongs to it and not to your app's classes, but i wouldn't use it on application level.

What's yours, and most importantly WHY?


My Conclusion (please feel free to add your comments to produce the most informed decision)


Application Level Classes:

  • I decided to go with 1 Letter Prefixes (like CMyClass). The main reasons are for file organization purposes (e.g. better grouping in Finder), and it still uses less class name letters than prefixes with length 2 or more.
    • Use the prefix 'C' for cocoa classes (e.g. CAudioController.h)
    • Use the prefix 'U' for utility collections (plain C, e.g. USystemAudio.h)

Framework Level Classes:

  • Prefix classes with 2 or more custom letters, preferrably unique, since it will probably be shared with other apps.

Categories

  • Categories are named as follows: NSClassName+ExtensionPurpose
A: 

you definitely should prefix them. if there is a collision, the behaviour is undefined.

what actually happens (last i ran into this) is that the binary is loaded, but your class is not loaded if another (objc) class with that name has already loaded. i'll let you figure out which implementation you'll get when you create an instance of this class ;) such a collision will likely result in a crash or a lot of swallowed exceptions (and a non-functional app). a lot of developers use 2 uppercase letters, which is (all things being equal) 26*26 chance that they will use the same prefix. again - this has happened to me soooo.... it is best that you do it to avoid rewriting a lot of code later on.

Justin
Rewrite? Or search-and-replace?
David M.
Indeed. The worst case scenario of one of these situations is actually not that bad at all.
Jonathan Sterling
A: 

There is a very good guidline by Scott Stevenson on how objective-C code should look like. Checkout the following links.

http://cocoadevcentral.com/articles/000082.php
http://cocoadevcentral.com/articles/000083.php

These links will also answer your question how you should name your classes and why.

itsaboutcode
+5  A: 

My general approach is to prefix class names that are part of a framework or loadable bundle i.e. classes that might be shared amongst several applications and with other frameworks, but not to bother with classes that appear as part of a standalone application.

If Steve Jobs granted me one wish it would be to have name spaces in Objective-C 3.0 (which would be available tomorrow).

JeremyP
personally i despise those prefixes. my opinion is exactly like yours in this case. i've never had a conflict with framework classes yet by not using prefixes and they somewhat decrease code readability. in frameworks they are ok to signal "hey i belong to this framework and not to your app code". and if there was a conflict the compiler would report this issue anyway (in most cases).
Erik Aigner
I agree with Jeremy's approach. Since Apple prefixes all of the global names in its libraries and frameworks (i.e., not just classnames, but typedefs for structs, enums, etc.), and any decent third-party framework should follow suit, apps can best avoid collisions by *not* using prefixes at all.
jlehr
+1  A: 

I use a prefix, even in application code that won't be shared -- mostly for consistently. I generally use a 2-letter abbreviation for the app or framework name in which the code originated, unless a different prefix (e.g, 3 letters, or a short descriptive word) makes more sense.

mipadi
The 2-letter prefix should work most of the time, but I thought I'd point out that technically Apple reserves all of those prefixes for themself. So their suggestion is to always use a 3-letter prefix.
Alex Martini
Where does Apple state that they reserve *all* 2-letter combinations? Just about every Mac project uses a 2-letter prefix.
mipadi
In [WWDC 2010 videos](http://developer.apple.com/videos/wwdc/2010/) Application Frameworks, Session 130 - Future Proofing your Application.
0xced