Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For example, the Objective-C convention is to prefix the symbols with two or three capital letters which are abbreviations of the project: NSString, CABasicAnimation, MGTwitterEngine… In C, many projects also do this (OpenGL and nginx for example).

Is this also considered namespacing or am I missing something?

share|improve this question
up vote 9 down vote accepted

I think it's not technically namespacing in the modern sense, it's more like the ancestor of namespacing. It's done for the same reason (disambiguation) and has many of the same benefits.

share|improve this answer
Prefixing has the benefit the symbol has unique name across the entire program, this makes finding where a particular symbol used easier by simple text search. – Calmarius Jan 16 '13 at 12:53

There's a number of senses of the word "namespace". In C, for example, structs are in a different namespace to local variables - traditionally, you'd refer to "struct mystruct" rather than just "mystruct". I forget for current C, but in C++ you can normally (but not always) drop the word "struct" - the struct namespace leaks, but only when it doesn't cause ambiguity.

I think moz is about right for naming convention "namespaces" like this.

Name prefixes are common in C to avoid ambiguity when multiple libraries are used together. Making those prefixes semi-optional makes sense in that context. Modules have been around for a long time in some languages, and obviously at a superficial level do the same thing - but the "prefix" is typically optional. C++-style namespaces are somewhere in-between - a kind of module that isn't a module.

So yes, I suspect there was a kind of "OK - modules can help fix this problem we have, but we don't really need modules because we have #include and classes already - let's adapt" logic to C++ namespaces.

Of course, as it turns out, #include and classes don't solve all your modularity issues, even with namespaces - but that's another story.

share|improve this answer

Definitely not.

A powerful IDE (like Visual Studio, especially VS with Resharper) will help you refactor and rename namespaces very easily with almost absolute certainty.

To do a similar renaming or refactoring operation on prefixed symbols could only be done with a grep utility, and even a grep utility could never be so certain that all applicable symbols and types (and only applicable symbols and types) were changed.

share|improve this answer
You could make a similar argument for C++-style namespaces. Just because you've left a namespace, doesn't mean you can't re-enter it - they aren't locked. Just look at all the standard library headers that make separate contributions to the std namespace, for example. So it's perfectly possible for two libraries to use the same namespace. By definition its the same namespace, but not by intent, so when you refactor your code there's a chance your IDE will decide to refactor some of that library you happen to be using too. Unlikely, but it can happen. – Steve314 Feb 28 '11 at 5:53
So functions like strncpy() and strcmp() can be refactored by the IDE or grep? Would that break any code? – JBRWilkinson Feb 28 '11 at 14:15
@JBRWilkinson: My point exactly. – Jim G. Mar 1 '11 at 0:37

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.