CocoaDev

Edit AllPages

When making a program (or framework), you sometimes run into a need to keep your classes visibly separate from all the other classes. Some ways of doing this are to use no prefix (so have, for instance, AppController, SomeKindOfDocument, et cetera as your classes), or to use the My prefix (as described in MyApp), or to ChooseYourOwnPrefix.

Choosing a prefix is a mix of looking at which frameworks you’re including now (e.g. FoundationKit or AppKit; so you probably never want to prefix your class names with NS), and which frameworks you might conceivably include later. It’s all a matter of marking out “namespaces”, though it’s admittedly not the best way of doing it (Java seems to have done it pretty well, but that’s not so helpful to the ObjC coders).

You might want your prefix to be specific to your company (Apple reserves NS for its classes, for instance; intruding into that could easily backfire on you), or to your project. It’s really up to you. Just make sure you choose carefully, or it could come back to haunt you.

Your prefix really doesn’t have to be an acronym. You can pick one at random, if you wish, or even use your name (RobRixWackyObject would be a bit on the ironic side, though). Project names are also good; SuperAppController is very clear in its intent.

WhenAreNamespacesNecessary?

AlternativesToPrefixing. The best alternative seems to be to use a long “formal” class name in the com.whatever style, but to use a #define to shorten it in your code. –DustinVoss (and I moved stuff off this page to that)

Here are a few prefixes to avoid, since there are significant amounts of code using them:

Please add more if you think it would be useful. Perhaps your own. Yes…

I found that Apple stole my initials!! Anybody knows a good lawyer out there? –NirSoffer

Isn’t LS LaunchServices’ prefix? –EnglaBenny ( My prefix is EB and I don’t understand why YOU have to reserve that)

Yep, it is. Luckily, I don’t use LaunchServices. I’m careful. But it’s a good demonstration of where a conflict could potentially occur.

– RobRix (I’d reserve RR, but no, I wouldn’t.)

“Luckily, I don’t use LaunchServices. I’m careful.” This doesn’t matter. All you have to do is link launch services and you’ll have a problem. You don’t even have to link it directly. If you link app kit, and app kit links launch services, and you have names that collide, you’ll be in trouble. My guess is that app kit does link launch services. Jon H.

We only really need to worry about collisions if we’re going to be using someone else’s code. There’s a pretty good chance I’ll use MOkit or Omni or the MPW stuff, but for some of the smaller developers (HogBay?), I don’t think I’ll be using a lot of their stuff. No reason to contort the prefix you want to use just because someone small beat you to it first.

If you are only using two letter prefixes thats 26 x 26 = 676 possible combinations. I don’t think there are only 676 cocoa developers in the world. Allowing lowercase gives you 2704. 3 letters are better: 26 x 676 = 17576 possible combinations. 4 letters give 456976.

Is there a cocoadev prefix? Then people who want to give ownership of their code to cocoadev could use it. CD is already taken I believe. – MikeAmy

How ‘bout CCD as the CocoaDev prefix?

—-Let’s be thorough. Uppercase only: two characters– 676 possibilities; three characters– 17 576; four characters– 456 976. Allowing for mixed case gives us 2 704; 140 608; & 7 311 616 respectively. And that’s assuming A-Z. Anyone want to try thsi with UNICODE? heh…

Vanity, and the goals of creating brief, readable, and self-documenting code collide fundamentally with namespace safety considerations. Don’t they?

There may indeed be fewer than 676 Cocoa developers out there who truly merit their own Leading Uppercase Digraph. I am not one of those. I suppose I shall call them LUDites, now.

For the rest, when dealing with mundane class names, one ought prudently to insert one’s digraph anywhere it fits safely, rather than into the first hole it finds.

Just out of curiosity, why are you calling the prefix a digraph? Is that not short for directed graph?

Consult a dictionary. A Digraph (literally ‘twice writing’) can mean “two letters”. You can get pedantic that a digraph is two letters that form a single sound (like ‘ph’ or ‘sp’), but in the sense of a two letter prefix, the term makes a lot of sense.

Two letters that form a single sound (phoneme) is usually referred to by “dipthong” (yes, it’s a horrible word!).

BTW, “sp” is not a dipthong - it actually consists of two phonemes. But that’s getting FEARFULLY pedantic. ;-)

No DS expert, I was not aware that “directed graph” had been granted an elision to “digraph”; very ill-considered IMO, but so be it.

Those data structures folks should have consulted a dictionary before appropriating it. For “elision”, consult a dictionary.

“Digraph” is just so-much-less-cumbersome than “two letter combination”, and has some serious semantic priority when used as such.

Especially considering its relevance to the present discussion.

– DS (my own digraph, ironically enough)

“Bigram” is used in cryptography and statistical text analysis and is unconnected to sound. –AllanBaruz

OK, from now on I’m going to use the suggested CCD as the cocoadev prefix. I already have code that I want to give to cocoadev under GNU licence. see CCDMessageDistributer. – MikeAmy

Is there a real purpose to this page? I highly doubt someone won’t use DB because DevBoys claimed it (here). Have they ever released anything at all?

Not that I can see. I think the real purpose to this page is that one-person “shops” can get that thrill of legitimacy. “see! I’m IMPORTANT because I’ve staked out my PREFIX!”

The purpose of this page is clear: it allows us to try to avoid name collisions. If someone wants to use DB then this page will show them that maybe it isn’t a good idea. It also shows who they should talk to about the prefix. In your DevBoys example, someone who wants to use DB would know of a potential conflict and could ask them if they are actually using it.

So, I think that there is a very real purpose to this page even though it isn’t actually enforced (which shouldn’t really matter since such name disputes would make the developers look very petty unless they already have a large code-base which uses the names).

While I think this page is valuable and relevant, I don’t think that name collisions need to be at the top of most Cocoa developers concerns. Ask yourself how many name collisions you would have had if you hadn’t used a 2 character prefix. Any at all? I know in my Java development work ( which I do a LOT more of, since I get paid for it… ), I have run into exactly 3 class names that would have had name collisions on projects if it weren’t for package names. 1 is in Sun’s own java code (java.util.Date and java.sql.Date). The other two were in very large projects I was on. The collisions were between a class we had, and a class in some library. One project had over 100,000 lines of code. The other over 400,000.

So far in my open source code, I’ve had no cases of name collisions being reported. Might be due to lack of use, might be due to a sufficiently unique name.

I don’t mean to belittle the problem of name collisions. It IS a problem. I beleive a language based solution should be created. It is by far the cleanest way to manage a language based problem.

In practice, I’m not too worried about it. The problem is more significant for framework developers than those that consume frameworks in order to deliver apps. So far I don’t think we’re close to having 676 Framework developers to worry about. We may very well one day..

In my non-framework code, I don’t bother with prefixes.

–TimHart

anyone else feel that the list on this page could use to be split up into prefixes to definitively avoid because Apple uses them (NS, CF) and prefixes which are simply ‘reserved’ by 3rd party developers?

Not really. Only the third party prefixes are interesting, because the Apple prefixes are documented elsewhere (and mostly well known).

Removed BartasTechnologies (BT) - I anticipated releasing a framework containing my own tricks, shortcuts, and other unsavory Cocoa-coercions, but have yet to do so. ;-) Couple that with the discussion here, I’m convinced it’s not really worth staking out my own claim to a two-letter prefix anyway, growling jealously at passers-by …

Apple provide clear documentation on class naming and advice on avoiding namespace collision. This issue only affects code segments that co-exist within a common process. Such relationships include plug-ins, frameworks, and injected code.

Preventing Name Conflicts:

http://developer.apple.com/documentation/UserExperience/Conceptual/PreferencePanes/Tasks/Conflicts.html

Code Guidelines:

http://developer.apple.com/documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html

There is no formal or enforced register of restricted prefixes. Nor is there any need.

Unless you are developing a code segment destined to exist within a shared environment - and most of us are not dealing with this special case - you do not need to overly concern yourself with namespace issues. Focus on building a great application with a fantastic user experience. – GCM

I just added a bunch of Apple prefixes to the list: LaunchServices (LS and UT), CoreGraphics (CG), CoreServices (CS, with examples), Enterprise Objects Framework (EO), CoreImage (CI), CoreVideo (CV). –boredzo

Added BitSpinn.org (Bso) - most of my frameworks will be GPL’ed or have a public API – “shirk”

Removed Myko Games; it’s dead.

Changed Skorpiostech from ST (which is used by the OCUnit stuff) to SKP (SKT was Sketch, thanks boredzo!).

Apparently “Ninja Kitten” won’t learn the concept of alphabetical order until he/she becomes a “Ninja Cat” … fixed the list for him/her.

Refactored Bso to just BO (BitObjects)– “shirk”

Allowed myself to add my prefix (BTH), since I sometimes publish some APIs. – Tomek Wójcik.

A more comprehensive listing of prefixes used by Apple can be found here:

http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/OSX_Technology_Overview/SystemFrameworks/SystemFrameworks.html

Added myself (for privately released stuff) and my company Harpander to the list. I hope I don’t ask take too much from so relatively small name space :). – Harry Flink

Added EG for Exit Games – Kaiserludi

Added ZP for Zapstreak – Cz4rek

Added FES for Frisky Electrocat Studios and MFR for Madefire – Danimal

Added DB (Dropbox SDK) and GT (Objective Git). I’m not behind either of these projects but use both of them and figured they should be mentioned here. – User:Peterkelly Peter Kelly