If you work with SharePoint, you'll see classes like SPList, SPSite etc.

I've seen variations of this on other projects, in other technologies, e.g. for a CRM project, classes named CRMLoggingFactory, CRMEntity etc.

This stands out when you look at the code and you know what the prefix corresponds to, but when do you draw the line? What are the conditions for a class to be prefixed by the project name, company name, etc. (i.e. the "domain name" of the project)?

closed as primarily opinion-based by durron597, GlenH7, Ixrec, user22815, user40980 Aug 15 '15 at 20:40

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.


This will at least partly depend on the language. Id say it is, in general, bad practice in languages that provide proper namespace facilities but good practice in languages that don't.


This is an indication that the environment has weak namespacing facilities, in Java, C++ or C# this is a tautology and a serious code smell. In C with a flat namespace this would be acceptable for public facing API functions.


I would say that the line should be drawn when the class name seems somewhat generic but has a very particular implementation and meaning that is specific to the containing library/framework/api. Also if the library/api/whatever is expected to be used in the context with other compenents that may have classes with similar or identical names. You could also use namespaces to help with such problems, but that may not be available in all languages/environments.

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