Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Would it be acceptable for some very generic utilities or classes to be added in the System namespace?

I'm thinking of really basic stuff like a generic EventArgs (EventArgs<T>),

Use case: would be shared in a company's core library (so that it can be recompiled in a new project as-is, without changing the namespace);

share|improve this question
    
-1. No, System or System.Core or System.* are NOT your libraries, no mather how much useful and similar your utility classes are. A <MyCompany>.System.* namespace is a better solution. –  umlcat Oct 27 at 17:38

6 Answers 6

up vote 21 down vote accepted

Not acceptable.

Could you? Yes, but System namespace is for framework base stuff. Even Microsoft does not put their own stuff into the System namespace (for example: such as C# compiler APIs or Registry).

System namespace is shared between Microsoft .NET, Mono, and DotGNU.

I would recommend using your company name, and then put the basic stuff in that namespace.

share|improve this answer

Microsoft have created a set of guidelines for namespace conventions.

This link is here: Microsoft Namespace Naming Guidelines.

share|improve this answer
2  
this is the line you need: CompanyName.TechnologyName[.Feature][.Design] –  rmx Mar 12 '11 at 13:21

No, no, no. What would you do if the next .NET release contains a class with the same name? You are screwed as you would have to go through all of your files that include that class and rename all instances. You never add to a library to which you have no control. The easiest solution is to reverse the company URL. For example, if your company site is fred.com, create your classes in com.fred. It's pretty common to follow this naming convention.

share|improve this answer
6  
+1 for providing a clear and realistic reason to why it's a bad idea. –  Statement Mar 12 '11 at 19:52
5  
This is the main reason namespaces were invented, right? –  Statement Mar 12 '11 at 19:53
8  
The easiest solution is to reverse the company URL. For example, if your company site is fred.com, create your classes in com.fred. It's pretty common to follow this naming convention - in Java world. In .NET it's customary to use CompanyName.TechnologyName[.Feature][.Design] (as @Dal / @rmx pointed out) –  Konrad Morawski Mar 18 at 9:21

Fully correct answers here, but no rule without exception: if you create something like LinqBridge (which is a .NET framework 2.0 replacement for .NET fw 3.5 classes in a 100% compatible way), then usage of the System namespace is mandatory. Or to answer this in a more general way: own usage of the System namespace is only a good idea if you have to port some higher version framework classes to a lower version, because you cannot upgrade your production version to the higher framework (and I guess this is the only valid reason for using this namespace).

share|improve this answer
3  
I'll agree with this, because it's explicitly invoking the reason @SnoopDougieDoug cited as the best reason not to do so: Future naming conflicts. In this case, you want the conflict so your code will transition seamlessly when you are able to move to the higher version. –  Bobson May 21 at 21:26

Yes, you can do it. VS might report various false errors, like classes it doesn't find but when compiled everything will work ok. It is generally NOT recommended for already mentioned reasons BUT, I think you can do it in some situations.

In my case I did it for a shared code base which is compiled as libraries for 6 different .net based platforms (.NET basic, Xamarin, Window 8.1, Mac etc, each api having its own small differences). The compiled lib is then used by projects targeting each platform. For the Windows Store 8.1 Apps and Windows Phone 8.1 platforms the System.Collections had a whole bunch of classes missing from it: ArrayList, Hashtable, SortedList etc, all kinds of comparers, enumerables etc etc. While I am aware of the fact that these classes are not recommended and one should use generic alternatives (which are available for the Win 8.1 platforms), it is a HUGE task in our case to make such changes on the shared code, PLUS on the code of the consumer projects of the resulting libraries. Non generic classes are used all over the place, the dev started in 2002. And we are talking about tens of thousands of lines of code now... So in this case, I think it is ok to inject a few missing classes in System namespace.

share|improve this answer

Many correct answers already. But I want to add another perspective:

Using the System namespace tells the developer to look at MSDN, using the company's namespace tells the developer to look at internal resources for documentation.

It also makes the dependency on the company's library clear, which might be relevant when moving code around between different modules.

share|improve this answer

Your Answer

 
discard

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.