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.

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.

share|improve this question
1  
This question (and answer) may also be of use to you, with consideration to the answers already provided here :) –  Chris Cirefice Jun 24 at 7:45
4  
Your project leader is replicating the functionality of namespaces, badly. They gain nothing by doing so, and potentially lose. Shouldn’t this be an absolute no-brainer? –  Konrad Rudolph Jun 24 at 9:46
    
Would he volunteer to update all prefixes when the project gets renamed? –  Patrick Jun 25 at 15:32

2 Answers 2

up vote 10 down vote accepted

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:

Class Name Prefixes

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.


Namespaces

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!

share|improve this answer

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.

share|improve this answer
1  
Personally I find . notation a lot easier to read and work with. Not to mention, if the OP is using Visual Studio (most likely), then Intellisense would help immensely in the namespace case. You lose some of that capability if you prefix, but that's up to him to decide. –  Chris Cirefice Jun 24 at 7:44
4  
There are lots of large projects out there and if you look at the code, you won't see any thing like that. You say "It won't hurt you", and you say there are hundreds of classes in the project. Now consider writing ABC in front of every class and every reference for thousands of time. How won't that hurt? –  Mert Jun 24 at 10:24
    
@Mert you have to write something for a class, and having several classes all called User in different projects is a real PiTA, especially if you don't have intellisense for whatever reason. It doesn't hurt you to type out ABC in front of every class (actually it'll be different for each project so you'll have ABCUser and DEFUser etc). Unless you have extremely sensitive fingers it won't hurt at all. Looking at some .net projects and seeing the massively long class names, it seems its not much of a problem adding all kinds of descriptive text to each class and method anyway! –  gbjbaanb Jun 24 at 17:04

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.