The Stack Overflow podcast is back! Listen to an interview with our new CEO.
53

Reverse Domain Notation has its origins in Java, but is widely used in many platforms, such as Android Packages, Mac OS X Packages, JavaScript, ActionScript, and more. The practice is extremely useful because it provides a decentralized system for namespacing software. There is no need to apply to a centralized agency for a namespace; simply use the domain ...


34

In theory, loose function-data coupling makes it easier to add more functions to work on the same data. The down side is it makes it more difficult to change the data structure itself, which is why in practice, well-designed functional code and well-designed OOP code have very similar levels of coupling. Take a directed acyclic graph (DAG) as an example ...


30

There is a nice document that contains a lot of rules that you should follow to be in line with Microsoft: Framework Design Guidelines. One thing that you should change: Do not name classes as their namespace. That will lead to compiler mixups. Just don't. Find a better name for either the class of the namespace.


25

Avoid using using in headers, because that breaks the purpose of namespaces. It is ok to use it in source files, but I would still avoid it in some cases (for example using std). However if you got nested namespaces, it's ok : namespace A { namespace B { namespace C { class s; } // C } // B namespace D{ using B::C::s; } // D } // A


21

Namespaces are not just for autoloading classes. They also prevent naming conflicts. In fact, that's their primary purpose. Say you have a project that needs a class named User, to store info about users of your application, but a plugin also uses a (different) class named User to store information. Namespaces let you create your class within one namespace (...


21

The two main reasons for using namespaces are to avoid name collisions, and to add logical grouping. But since exception class names typically have the form "XYZException" (and other classes have not), those two requirements are already fulfilled by this naming convention. Thus adding an additional sub-namespace is unneccessary in a context where everybody ...


16

In general terms, any unique identifier would serve for a namespace; but since it's supposed to be globally unique, the standard would have to either mandate some arbitration authority, or use another resource that is at the same time globally unique but easy to get hold and to prove it's yours. Oh, look! if you have a domain, it's obviously only yours, and ...


16

Using static classes as namespaces defies the purpose of having namespaces. The key difference is here: If you define CategoryA, CategoryB< as namespaces, and when application uses two namespaces : CategoryA::Item1 item = new CategoryA::Item1(); CategoryB::Item1 item = new CategoryB::Item1(); Here if the CategoryA or CategoryB is a static class ...


13

It's because using namespaces reduces the chances of name conflicts tremendously, and because using your domain name (which has already been regulated) is a good way to create a global namespace. By reversing the domain part in the namespace, you make it sortable; all names that belong to your little chunk of the namespace universe are sorted together. And ...


13

In case you didn't know it already take this insight: The concepts of object-oriented and closures are two sides of the same coin. That said, what is a closure? It takes variable(s) or data from surrounding scope and binds to it inside the function, or from an OO-perspective you effectively do the same thing when you, for example, pass something into a ...


11

In C++, it's generally frowned upon- especially using namespace std. That std namespace has so many names, many of which are very generic algorithms, you can get some extremely nasty surprises when using namespace std. Something like using std::cout; isn't so bad. But never, ever, using anything into the global namespace in a header file. That's a firing-...


11

You can use the using alias directive to avoid having to disambiguate everywhere, e.g. using HttpRequest = MyCompany.MyProject.HttpRequest;


11

When putting a using statement in a source file, PLEASE, just pull in the things you need. For instance: using std::string; using std::ostringstream; The issue here is that if you do using namespace std; you pull in EVERY SINGLE THING from std into the global namespace. Which leads to very interesting error messages when you accidentally use a name in ...


11

Well, currently the main difference is a namespace is designed to be augmented in separate files. If you try to add a new nested class to a class, you get: test1.cpp:3:7: error: redefinition of ‘class NamespaceClass’ However, it only works that way because it was defined that way. It wouldn't be that difficult to rework the compiler to append to a class ...


11

The problem with trying to put each class in a package which has a semantically correct name for that class is that it tends to lead to packages that contain very few classes, or sometimes even just one class. This in turn leads to a multitude of packages. A more pragmatic approach to package naming is to simply help you find stuff. Keeping frequently ...


10

Your approach is not technically wrong (except a minor detail, see footnote) but it goes against established usage patterns and obfuscates code. I.e. it lowers readability and increases the likelihood of errors. That might be justified if it is outweighed by a clear and significant advantage somewhere else. And here lies the problem. Sjoerd already pointed ...


9

The name chosen for a namespace should indicate the functionality made available by types in the namespace. For example, the System.Net.Sockets namespace contains types that enable developers to use sockets to communicate over networks. The general format for a namespace name is as follows: <Company>.(<Product>|<Technology>)[.<...


9

Including a header into a namespace is prone to break various assumptions, and should not be done. Problems that come to mind are: It breaks include guards. If a header can only be included once, and you include it into the wrong namespace, then other code can't include it into the correct namespace within the same compilation unit. Or the other way round: ...


9

You're right that you shouldn't name the namespace the same as a type it contains. I think there are several approaches you can use: Pluralize: Model.DataSources.DataSource This works especially well if the primary purpose of the namespace is to contain types that inherit from the same base type or implement the same interface. Shorten: Model.QueryStorage ...


9

It's very difficult to determine how effective your naming strategy is in isolation from the rest of your code. The namespace should give some idea where it fits in the broad structure of your codebase, and the class name would usually describe what sort of functionality or concept it represents within that area. Caveats aside, in your specific example, ...


8

Namespaces are units of logical grouping. Assemblies are units of physical grouping. That is, break things into different assemblies only if they are going to be deployed separately. With the example you have given, one may want to use ISerializable and Serializable without dragging in DataContract, but if one does use DataContract, it logically belongs ...


8

No, you should definetely not abandom namespaces! Instead, you should organize your code better, and maybe check your architecture again. First, you should not use using namespace MyLibrary::MyModule1; or using MyLibrary::MyModule1::MyClass1; in a header, to avoid namespace polution, since there is no way to undo that (see this question and answers). ...


8

Looks like a wrong approach, for several reasons: The things that you don't want to be "visible" to outside, should not go into headers. Instead they go into anonymous namespace in the source file. Your __local__ things are still visible, and everyone can access them


8

When the documents mention second-level, they're referring to the section of the namespace indicated as (<Product>|<Technology>). The product or technology should be version independent. So no, technically Microsoft isn't violating its own guidelines, however admittedly using versions in namespaces is probably not a great idea. The proper ...


7

It should be in the namespace of your application Since you are extending the class to add features for your application, the class should be part of your application's namespace, not a different one. Now if other applications would also be using this derived class in addition to your 1st one, then I would make a separate library file (and namespace) which ...


7

It's about type coupling: A function built into an object to work on that object can't be used on other types of objects. In Haskell you write functions to work against type classes - so there are many different types of objects any given function can work against, so long as it's a type of the given class that function works on. Free-standing functions ...


7

this creates an entirely new issue where there are two separate hierarchies — one for namespaces, and another for the file system. That's not an issue at all though, it's perfectly normal. Coupling the namespace and filesystem structures is (so far as I know) unique to Java. Trying to import this idiom into any other language where it isn't already ...


Only top voted, non community-wiki answers of a minimum length are eligible