Abstract: Is it acceptable to include the type name in the variable name?
I am working with C# MVVM, and I have a lot of
ICommand properties in my ViewModel, named various things like
WriteSomething, etc. The "rule" for ordering members in C# is alphabetically, so I have my commands strewn throughout the file. Even if I sort them manually, it can be difficult to remember that
GetSomething is a
ICommand, especially when there are two methods for each command (the
void execute and the
bool can execute) and a
MenuItem the command is bound to (the menu is generated dynamically in code-behind).
I would like to name my commands
CommandGetSomething, in which case I could then have
MenuItemGetSomething so that all of the parts for the different commands are at least alphabetically next to each other (
ExecuteDoSomething would be next to
ExecuteGetSomething would be next to
Am I even trying to solve the right problem here? The ViewModel has about thirty different commands, plus other stuff, so it is important that the file is ordered logically. I use ReSharper to sort the contents, and while I wish that I could sort by type name directly, the closest I can get is alphabetically (which is default).
This is typically referred to as "Hungarian Notation", and is overwhelmingly frowned upon by every source I've ever seen.
The problem is, what happens if you change the underlying type down the road? Now you're forced to either rename all your associated variables, or deal with a potentially misleading name.
Sure, with a good IDE you can easily do a bulk rename if need-be, but at the same time, if you have an IDE capable enough to pull this off, it'll likely also be able to automatically infer the type, and maybe even display the associated documentation.
Let the language and IDE deal with typing. Encoding that information into your names just opens up the potential for mistakes down the road when things inevitably change.
I've always put the name of the interface or class that I am implementing/inheriting at the end.
I believe it should be
GetSomethingCommand. Of course if your implementing multiple interfaces then the convention doesn't really work, so use with judgement.
I took this from MSDN:
The second part of the derived class's name should be the name of the base class. For example, ApplicationException is an appropriate name for a class derived from a class named Exception, because ApplicationException is a kind of Exception. Use reasonable judgment in applying this rule. For example, Button is an appropriate name for a class derived from Control. Although a button is a kind of control, making Control a part of the class name would lengthen the name unnecessarily.
There are several interesting references that do recommend not to encode types within variable names:
All the arguments put forward about the subject are rather language neutral and should be applicable to C# as well.
But as everythig related to style and conventions, this recommendation shall not become a dogma. R.C.Martin also recommends that names shall reveal intentions. In your case you're in a grey zone: it's not recommended to encode the type
Command as prefix. However starting a variable with
Command also reveals the intentions about the variable.