MVVM and naming conventions [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

Update: Thanks for closing my question because it might solicit opinions or discussion. That was the point as spelled out by the disclaimer below. Will someone please reopen this?

Disclaimer:

For starters, I realize how this question and possible answer isn't very black and white, but I am at an impasse and 开发者_StackOverflow中文版I need some different points of view.

Question:

When I am working in WPF, I often use the MVVM pattern to make things happen. In any given program I will have a bunch of View Model classes that all derive from a class called 'ViewModelBase' and it has been my habit to suffix the class names with 'ViewModel' However I am finding that I wind up with a lot of classes that have very long names such as...

InputDataViewModel

CalculationsViewModel

and so on. I like that they have some context in their name, but they can be a bit cumbersome when it comes to generic programming, etc. I am beginning to come to the opinion that the fact that they all derive from 'ViewModelBase' is enough information to identify them as view models and so the suffix on the names is becoming more trouble than it's worth.

Does anyone else have a similar experience or insight to offer on this issue? Pros, cons, etc?

Also:

No, I am not using an MVVM framework like caliburn, MVVMLight or anything like that.

---

Assuming that you are using a good IDE, like Visual Studio, you really don't need to add ViewModel. This is because Visual Studio's intellisense makes it easy to see what a class derives from, the methods it supports, etc. The benefit of adding the suffix is that people who don't use a fancy IDE will still be able to work with your code.

Also, you might have other classes that involve Calculations. Adding a unique suffix to each class name makes it easier when you or another developer is quickly scanning over your code. Without the suffix, it may require a further lookup in another file to determine what a class does.