current community

your communities

more stack exchange communities

Stack Exchange
tour help
careers 2.0
Take the 2-minute tour ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
up vote 4 down vote favorite

I'm not too quite sure about what i should do about a grouped set of classes.

My situation: I have 11 classes that relate only to the class Character.cs, but all of those classes (including Character.cs and CharacterManager.cs) are within the namespace Models.Characters.

Which is the more "proper" or preferred way of naming the classes:

(examples):

CharacterDetails.cs CharacterSprites CharacterAppearance CharacterClientRights CharacterServerRights

or:

Details.cs Sprites Appearance ClientRights ServerRights

(They're all noticed in Models.Characters (so eg. Models.Characters.CharacterDetails, Models.Characters.Appearance)

Thanks in advanced.

share|improve this question
add comment

7 Answers

up vote 6 down vote accepted

Personally for me it"depends". Usually I would prefix everything with the word Character to keep things consistant, however if you have everything already under the Character namespace the Character prefix could seem redundant.

I could easily see going with the shorter convention of Models.Character.[X] if there never will be another class called Details, if there for instance could be UserDetails then Details and UserDetails could be confusing when looking back at the code weeks or months from now and I would personally prefer then the CharacterDetails option.

In the end it is your personal preference, what more accurately describes your domain, Details or CharacterDetails?

share|improve this answer
add comment
up vote 6 down vote

Personally I'd stick with the second method as that is what namespaces are for: grouping related sets of classes. The first method is just making the class names longer with negligible benefits.

share|improve this answer
add comment
up vote 2 down vote

Your namespace already is grouping its classes under the Characters umbrella, so I would not name your classes with the Character moniker.

share|improve this answer
add comment
up vote 2 down vote

There is probably no right or wrong answer here. I find myself prefering your first style, but I have used the second style as well. I think in this specific situation if I were a caller of your API I would find it easier to read code that used the first style.

share|improve this answer
add comment
up vote 2 down vote

It is really a personal preference.

I would favor

CharacterDetails
CharacterSprites 
CharacterAppearance 
CharacterClientRights 
CharacterServerRights

Because it is more readable.

You are typically going to have a using statement of 

Models.Characters.Appearance

Unless you are going to do the full notation.

I would favor anything that would increase readability. It might matter on the project and the team you are working with. If it is just you than do what you like best and would help you maintain the code in the future.

share|improve this answer
add comment
up vote 2 down vote

As long as you pick one and consistantly use that throughtout your code, then whichever one you choose is the right one.

My personal choice is your second option. If your namespace is character, I see no reason to use the prefix character in the class name.

share|improve this answer
 
What's wrong with this answer it's perfectly valid, so why the downvote? If you're going to downvote, at least have the common courtesy to say why. –  Jeremy Dec 21 '09 at 22:06
add comment
up vote 1 down vote

Think about ambiguity that may be created by naming class. For example if I have a class called "Thread" denoting "CharacterThread" (hypothetical) and if some other class uses two namespaces

Models.Characters System.Diagnostics

I will have to fully qualify the Thread name everytime I use it ... which can be a pain sometimes

share|improve this answer
add comment

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.