views:

274

answers:

5

I am building a CMS and the naming convention for classes has been debated between the other developer involved and myself. The problem arises specifically with "Page", as it is a public class available in a typical library.

A natural response would be to call it MVCMSPage (where MVCMS is the to-be name of the cms) or to rely on referencing the class through the dll (can't think of the term atm..) but both seem to have a hint of codesmell to them.

What would you advise?

Thanks

+4  A: 

I'd go with something other than 'Page'. The 'Page' class that is built into .NET is a very generic class that is commonly known as part of ASP.NET. You could easily confuse other developers (or even yourself, a few months down the road if you don't look at it for a while).

I usually go with a naming convention such as:

ApplicationName + "Page"

I also like to follow the MS .NET naming guidelines of only capitalizing the first letter of an acronym longer than 2 characters. Since 'MVCMS' can be confused for the 'MVC' architecture style if read incorrectly, I wouldn't use 'MvcmsPage' or 'MVCmsPage', I'd call it something like this:

MvCmsPage

This is descriptive and fairly easy to read and understand.

Of course it's really up to you. Mainly it's a matter of preference. Just don't use 'Page' as it will make some developers angry (such as myself).

Dan Herbert
I'd only call is "base" if there are derived types in the system. Otherwise MvCmsPage seems fine to me.
Robert C. Barth
I've removed the suffix "Base" from the class name. After people's feedback and thinking it over, it makes more sense to leave it out.
Dan Herbert
+3  A: 

I think the term you were looking for is namespace.

I don't think I would rely on namespace differentiation for such a fundamental class in the System.Web space. If you were writing a console-based notification mechanism then it might be ok, but since you're working in the web arena, I'd avoid it. My vote would be to use the namespace as the main differentiator and name it something simple, like ContentPage so you would have something like MvcCms.Web.ContentPage as the full name of the class.

If you do it this way you can import both your namespace and System.Web and still be able to differentiate the classes AND you have a short name that makes sense and isn't cumbersome to use or reference (when speaking about it).

tvanfosson
+1  A: 

To me, since you're developing a CMS, the object at the root is the Content. So either MvCmsContent, CmsContent, or just Content would seem fine to me. Isn't naming always the hardest part of a project?

Robert C. Barth
I appreciate the response but content won't work because it belongs to another portion of the project.Yea, naming was surprisingly difficult.
Chance
+1  A: 

We had a similar issue and just went with CMSPage. It's a bit less cumbersome than the MVCMSPage, but still obviously CMS and you can further extend that class for multiple systems in the future if need be.

Aaron
A: 

I'm thinking the "page" you're referring as the application's equivalent of a database record. As others are saying this it's a rather loaded term. Here's a few random ideas:

  • Node
  • View
  • PageRecord
  • CmsPage
  • WebDocument
  • ContentPage

Your choice should try to convey the essence of the object type. I'd avoid putting the product name into the class name. I prefer namespaces for that.

Cristian Libardo