开发者

Objective-C Class Prefixes [closed]

开发者 https://www.devze.com 2023-01-16 06:16 出处:网络
Closed. This question is opinion-based. It is not currently accepting answers. Want to improve this question? Update开发者_StackOverflow中文版 the question so it can be answered with facts
Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update开发者_StackOverflow中文版 the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this question

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


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).


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.


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.


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消