My project leader uses project based prefixes for class names, lets say projects name ABC, he create User class name as ABCUser. and he says he do this becasuse if he wants to make User.aspx Users get mixed. so I told him why not use namespace (Entity.User ie.) to make it specific but he against it. I would like to hear from you guys' opinion on this subject.
We code c#.net and using visual studio for projects.
Edit: This answer is not specifically geared toward project-specific naming, but I believe that the principle can be applied as well. In one of my applications, I have three separate VS projects which I do not separate with either namespaces nor class prefixes as a naming convention. Namespaces would be a possible way to separate the entities by project, and would be my preferred method of separation if I actually had a need for it.
In my experience in C#, namespaces exist for this very reason.
If you define a class Dog and class Cat, it is logical to put them in a namespace called Animals or Housepets (depending on your program's purpose).
It is not, however, logical to prefix the classes with what you would normally use a namespace for: e.g. AnimalCat as a class name.
The fact that namespaces can be defined inside other namespaces means that you have a great ability to create hierarchical organization. If you use prefixes for class names, that prospect promptly disappears. Consider the following two examples:
public class LanguageExtendedDictionary
{
public SortedDictionary<string> wordList { get; set; } // quick spell-check
public SortedDictionary<string, LanguageWord> dictionary { get; set; } // full entries
}
public class LanguageWord
{
public string word { get; set; }
public string definition { get; set; }
}
With this, naming schemas get cluttered real fast. In any large-ish application, you might have 50+ classes. Can you imagine trying to pass around data types like SortedDictionary<LanguageWord>? In my experience, long class names are hard to read, and harder to code down the line. Class names should (in my opinion) be as short as possible to accurately represent the entity that it is modeling.
Imagine if we had support in our application for many languages. Would you want to create a class with the name LanguageFrenchWord to dinstinguish between that and English? I certainly wouldn't.
This method leaves no room for class organization, which is extremely important, especially in languages like C#, Java, etc.
namespace Language
{
public class ExtendedDictionary
{
public SortedDictionary<string> wordList { get; set; } // quick spell-check
public SortedDictionary<string, Word> dictionary { get; set; } // full entries
}
public class Word
{
public string word { get; set; }
public string definition { get; set; }
}
}
You could initialize the instances like:
var word = new Language.Word(); // if declared outside of namespace
or even simply
var word = new Word(); // if declared inside namespace
This allows you to separate what entities are in what relationship, and to set them apart. These entities are grouped logically because they have to deal with language(s). This makes sense when the complexity increases. Maybe I would have a namespace for things that relate to French, and I would add French as a nested namespace under Language; e.g. Language.French.
With a using statement, like using Language or using Language.French, you can eliminate the need to call Language.Word(), and instead call Word().
I'll also mention that, as you see in the above example I don't need to use the prefix Language. while inside that namespace. So in ExtendedDictionary, I don't need to use Language.Word as the type in in the dictionary variable, because both entities are in the same namespace. This reduces a lot of name clutter. With the class prefix method, you can't avoid the clutter. With namespaces, it's part of the feature of the language and makes things inherently more readable.
As the complexity increases, using prefixes causes a lot of name clutter, and a huge lack of organization. There are likely lots of neat things that you can do with namespaces in C# as well that I am simply unaware of. They were created for a reason, and this is my primary use case for them. It seems like this is what your boss is trying to emulate (the behavior), so why not use the tools that are provided in the language to accomplish that?
A side note: as far as I know, the entire .NET library uses namespaces to separate classes; e.g. System.Text, System.Threading, etc. They seem like the appropriate structure to use!
I currently work on a large project where every class is prefixed with the project name. Strangely it helps quite a lot, if you have a file, you can find the class very easily.
Now I imagine this doesn't help much if you have a dozen or two files, but when you have many hundred... things are different. So its not a bad idea per-se, and it won't hurt you to have such a standard.
That said, there are other ways to skin cats. so a namespace for each project and keeping your files organised in some other way to ensure you can quickly determine which part of the project a particular file comes from would work too.
I wouldn't complain particularly. One name is as good as another, so what if its called ABCUser or ABC.User. Sometimes trivial standards like this are not worth the hassle of worrying about. Save your powder for bracket placement and #region usage.
