This question already has answers here:
Placing custom code in a System namespace
(3 answers)
Closed 8 years ago.
I have a class called ConfigurationElementCollection<T>
It's a generic implementation of System.Configuration.ConfigurationElementCollection
It's stored in our solutions', Project.Utility.dll but I've defined it as being part of the System.Configuration namespace
namespace System.Configuration
{
[ConfigurationCollection(typeof(ConfigurationElement))]
public class ConfigurationElementCollection<T> :
ConfigurationElementCollection where T : ConfigurationElement, new()
{
...
}
}
Is putting classes in the System.* namespaces considered bad practice when they aren't part of the System.* Base Class Libraries ?
On the face of it, it seems to make sense, as it keeps similar classes with similar functionality in the same place. However it could cause confusion for someone who didn't realise it was actually part of a non .net BCL as they wouldn't know where to go hunting for the reference.
While your class is similar it is still not part of the BCL. I would not put it in System.* because of this. It will cause confusion especially when one goes to use it and they have System.* referenced and then get a nasty can't find message when they go to use your class.... :-)
I'd recommend either replacing System by your company/project name or prefixing the namespace with your company/project name.
That way you make it clear that it's not part of the BCL, but exactly how it's related to them.
Also in the (admittedly unlikely) event Microsoft ever implement these classes/methods with exactly the same names you won't get a clash.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
For example, I name my file(console application) 'Hello', so do I have to write namespace Hello?If no, what is the purpose of adding namespace?
No, the namespace can be anything, they don't have to be the same as the filename. It is good practice to have the namespaces correspond to physical file paths (folders in your solution).
So if you have a file in .\Interfaces\ViewModels\Client, usually the namespace declaration in that file will be:
namespace DefaultNamespaceOfAssembly.Interfaces.ViewModels.Client { ... }
ReSharper even offers to fix up namespaces that are breaking this rule.
The purpose of the namespace is to
modularize your code by putting things that belong together (by functionality for example) in the same namespace,
reduce name collisions. Without namespaces importing an external library would result in hell if it were to contain classes with the same name as classes in your own code.
Probably there are more, but at first thought these come to mind, although these two should already be enough to justify their existance.
I name my file(console application) 'Hello', so do I have to write namespace Hello?
No, you can name it whatever you want.
If you're writing a library to be used by other code, and that library is the only (or main) source of types in that namespace, then it would be convenient to users for the DLL to have a name based on the namespace, because then they can easily remember that the UsefulTypes.CoolStuff classes all come from the UsefulTypes.CoolStuff.dll assembly. There's no rule that you have to do this, it can just be convenient if you do.
With applications this isn't anywhere near as useful; end-users don't care what namespaces you use and may not know what a namespace is. It might be useful if the application was a tool for .Net developers, but otherwise not.
If no, what is the purpose of adding namespace?
Exactly what it says; it's a space for names. By putting the names of classes, enums, delegates and structs into a namespace they are separated from other cases of the same name being used in other namespaces. You don't have to make sure that no library you used has something with the same name, unless you are actually going to use that thing with the same name.
When writing an application it keeps stuff from other assemblies out of your way. When writing libraries it's even more important, as it also keeps your stuff out of other people's way.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Consider for the question this String.Split overload, which takes a StringSplitOptions enum as a parameter.
Isn't it bad that the enum itself is public and accessible to everything that includes the System namespace? I mean, the enum is completely specific to options of the Split method, yet it's available outside of it's scope.
Perhaps there is a better way to model this, like putting the enum inside the String class itself, and accessing it by using String.SplitOptions for instance? I very rarely see this (I actually can't remember any such case now), so I assume it is not preferred for some reason. In general, I think reducing the scope of things is a best practice because you lower the chance of problems occurring by using a class/member in an incorrect scope, so to speak.
I'm using Split as an example here, but it is quite common for a Enum to be used only by a method or class in our code base too. I generally create the enum as a public type in a separate cs file like any other class, but I would love to hear other approaches to this 'problem'.
Update:
I just found this article that attacks this exact problem, with a Folder class and a Filter enum but again seems go against what I believe would be more correct in that case (placing the enum inside the class somehow). One of the comments in there from ToddM (which I happen to agree with) states:
...
But, even then, I feel your logic is wrong. Your main complaint
against embedding the enum inside of the class is that it will take
too long to type. Given how verbose C# tends to be, this is not really
a sensible argument. In VS, CTRL+SPACE is your friend.
Logically, I feel placing the enum inside of the class is far more
correct. Take your example: what is a MyNameSpace.Filter? Where does
it apply? I guess it's a filter for your namespace? It's impossible to
tell, especially if your namespace grows to contain dozens of classes.
Now consider MyNameSpace.Folder.Filter -- it is, in my mind, far more
intuitive that Filter applies in some way, shape, or form to the
Folder class. Indeed, another class can be added to the namespace with
its own concept of filter, one of whose members may be 'File'. Just
because you've introduced a new class into the namespace doesn't give
you the right to pollute that namespace with various 'helper' types.
If you are developing as part of a large development team, your style
is, well, rude.
...
It's an interesting idea to nest the enum in order to suggest that it has a reduced scope, or to give it better semantics. I have used this idea before in order to have both error codes and warning codes in a post-compiler I developed. This way, I could use the same enum name Code nested either in the Error class or the Warning class.
On the other hand, public nested types are generally discouraged. They can be confusing to clients who have to qualify them with the outer class name. Look at the related guidelines on MSDN. Some that are relevant:
DO NOT use public nested types as a logical grouping construct; use namespaces for this.
AVOID publicly exposed nested types. The only exception to this is if variables of the nested type need to be declared only in rare scenarios such as subclassing or other advanced customization scenarios.
DO NOT use nested types if the type is likely to be referenced outside of the containing type.
For example, an enum passed to a method defined on a class should not be defined as a nested type in the class.
I believe those guidelines were followed when developing the StringSplitOptions enum, and most of the others in the BCL.
String.Split() is public, so StringSplitOptions has to be public too. Both String and StringSplitOptions exist in the System namespace. Both have public scope. Neither is "available outside of [the other's] scope".
I think one of the reasons is that it would make every call using an embedded enum wider (the name of the class becomes a mandatory prefix).
I personally wouln't appreciate having to use ResultSetTransformer.ResultSetTransformerOptions every time I have to use this enum, it would make my line horribly long.
But as others pointed out, I don't think it's standard in the framework to embed enums in classes at all, possibly for this reason.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have proved to myself that the namespace is not required to compile and run an application. However, what are the dangers and pitfalls of not using a namespace? It creates layers that I am trying to avoid.
I know you're screaming but what about agile and abstraction so that 20 layers of abstraction exist between the code and the object. I'm not asking if it violates this or that flavor of the month agile thing. Just what, if any, real world issues come about by not using a namespace?
Edit:
Creating a stand alone class dll so no conflicts within the class project. Trying to avoid when I include it in other projects having to use full qualified name. myNamespace.myClass MyClass = new myNamespace.myClass();
From the comments it appears that naming conflicts are the biggest problem.
Guess I should use a using statement and buck up...
Namespaces have two principle uses:
First, they enable the consumers of your code to more easily understand, find and correctly use your code. There is a reason why the system diagnostic tools are in System.Diagnostics namespace. It's so that customers can know what the stuff in there is for.
Second, they are a mechanism for preventing name conflicts.
The first is actually by far the more important. Conflicts aren't that common. Still, they are possible and judicious use of namespaces prevents them.
If you don't care about your customers finding, understanding and using your code, and you don't have naming conflicts, then sure, skip using namespaces.
It creates layers that I am trying to avoid.
There are no real additional "layers" created. The namespaces purely allow a way for the types to be organized, and help prevent naming collisions as projects get larger and more libraries are used.
As far as the runtime is concerned, there are no namespaces - all types are fully qualified, and the namespace in C# just changes the type name. Leaving the namespace off just makes your type name more likely to conflict with other names, but will have no "real impact" on whether or not the code works, provided you don't use the same name more than once in your project, or use a name that's the same as a name of a type from a referenced assembly and imported via using.
Edit in response to comment:
What I mean by "it creates layers" is that when I create the object I have to add the namespace as a layer. (i.e. myNamespace.myClass MyClass = new myNamespace.myClass();) "
Note that this is only required if you don't have a using myNamespace; statement, or if you use multiple namespaces within the project. If you're always working within the project's default namespace, then you will not need to qualify the name.
It might be a good idea to compare what life without namespaces looks like. The C language does not support namespaces. And very early in its existence, the open() function was used to open files.
Which means that no C programmer may ever use the name "open" for their own function.
Painful isn't it?
Namespaces help you use short and descriptive names. They do not add layers, they only create longer names. That you can very easily write shorter, the using directive makes it easy.
You can end up with conflicts and isn't standard practice for C#. It won't truly hurt anything in the long run.
A conflict could arise if you named your class the same thing as another visible class. For instance, if you named your class Math and had a using System; using statement, there would be a conflict that would only be resolved by specifying System.Math.
Again, not the norm and not something that should be published outside of internal use, but it sounds like you already know that :)
It is said here
http://msdn.microsoft.com/en-us/library/fa13yay7%28v=VS.90%29.aspx (see also http://msdn.microsoft.com/en-us/library/s4wcexbc%28VS.90%29.aspx)
Use this option if you want to define
or create your own System namespace
and objects.
But how ? Where can I find some examples ?
Update: of course my question is not about how to create a namespace or a class but about an example of custom system architecture (an UML schema and source code).
For example could this be used to port .NET on other processors like iphone ? Does Mono use this ?
Is there some smallest possible example instead of whole commercial clr to learn from ?
How? Just write the code. Make a namespace called System that contains a class called Object and a class called String, and the compiler will pick that up and use it instead of the framework class library version. That's how the framework team does it. All you have to do is replicate all their work yourself and you too can be in the framework class library providing business.
Note that in many cases the compiler has been designed to expect that the types in the System namespace are exactly as they are documented to be. I've had bug reports in the past - extremely confusing bug reports! - where someone has redefined, say, System.Collections.Generic.IEnumerator<T> to have different properties and methods than the "real" one, and then they're all surprised and vexed that the compiler generates crazy broken code for a "foreach" loop. If redefining the basic interfaces is the sort of thing you want to do, consider writing your own C# compiler too. Ours is by design not robust in that scenario.
I don't know why you want to do that but you just have to create a custom "System" assembly (like a standard library) and use it as a reference in your other project with /nostdlib+ set.
namespace System
{
public sealed class String : IComparable, ICloneable, IConvertible, IComparable<string>, IEnumerable<char>, IEnumerable, IEquatable<string>
{
...
}
}
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
Should Usings be inside or outside the namespace
sa1200 All using directives must be placed inside the namespace (StyleCop)
Is this just for code readibility or is there any actual advantage to doing so?
Does it help the GC somehow?
It definitely won't help with GC.
Here's the discussion about two styles:
https://learn.microsoft.com/en-us/archive/blogs/abhinaba/stylistic-differences-in-using
https://learn.microsoft.com/en-us/archive/blogs/abhinaba/do-namespace-using-directives-affect-assembly-loading
If you have multiple namespaces in your project, you can limit which namespaces are used by each one individually.
This might come in handy if there were class names in two different namespaces that were the same. One might be the default in one part of your project, while the other could be the default in another.
Yes they look for some really fringe cases for these rules.
There is no runtime difference. It's purely a compile time (and development experience) change. The file, compiled IL will be identical in either case.