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 libvs some_lib::file_functions::openFile(); 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?
API naming and namespacing
api;source code;api design
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. com.google.android.maps). 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.