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

Is it right or more beautiful to name the functions with an prefix, like in Qt? Or using "many" namespaces, but 'normal' names for functions? For example,

slOpenFile(); //"sl" means "some lib"



Update: I've read somewhere that the first variant(using some prefix) is better, because the API users can perform 'fast' search among the documentation and in the Internet. E.g. by typing the magic prefix search engine starts to advice the exact functions. Is it enough to use the first variant?

share|improve this question

closed as primarily opinion-based by durron597, Snowman, Kilian Foth, Dan Pichelman, GlenH7 Jun 30 '15 at 18:51

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Sometimes you have no choice but use prefixes. C and Objective-C come in mind. – mouviciel Jun 27 '11 at 10:40
up vote 3 down vote accepted

The latter is better, if possible.

  • In many languages (including C++), you can simply use/import packages/namespaces, so that you don't have to spell out the whole path repeatedly. In contrast to that, prefixes always have to be used.
  • Namespaces make it easier to avoid collision. Many libraries are simply prefixed by the domain of the library creators (e.g. There's only 676 possible two-letter-prefixes, but there's definitely more than 676 libraries out there. Damned is he who needs two with the same prefix.
  • Namespaces allow nesting, so you can have some_lib::file_functions::openFile and some_lib::file_functions::closeFile and some_lib::sound_functions::beep, while you can't do that with prefixes: slOpenFile, slCloseFile, slBeep. Nested namespaces allow you to communicate structure.

As for the claim, that prefixes make searching easier. Even assuming it is true (which IMHO is bs): You want to design a good API. Well, a good API comes with expressive, self-explaining function names and enough documentation to cover any ambiguity.

share|improve this answer

These days some_lib::file_functions::openFile(); is in fashion as this conforms to proper design pattern and fulfills OOP concept better.

It is very important to give a meaningful API name.

share|improve this answer
I see no objects here. – Tobu Jun 27 '11 at 17:20

Python's "zen" (import this) says:

Namespaces are one honking great idea -- let's do more of those!

I'd stick with that in the context of python code. I also find it logically better than using prefixed names. Prefixed names to denote that remind of things like using two lists side by side to act like a map in languages that don't support them..

share|improve this answer

Using prefixes, can be easier, at first, but become complicated at last. It is better to get used to namespaces, some programmiong languages allow namespaces alias to replace long multilevel namespaces for a single identifier in your application.

Unless your programming language doesn't support it, I advise you, to get used to namespaces.

I haven't work with QT, but, maybe it has a way to use both prefix and namespace ids.

share|improve this answer

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