Including the type name in a variable name

Question

Abstract: Is it acceptable to include the type name in the variable name?

My scenario:

I am working with C# MVVM, and I have a lot of ICommand properties in my ViewModel, named various things like GetSomething, DoSomething, 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 ExecuteGetSomething, CanExecuteGetSomething, and 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 ExecuteWriteSomething).

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).

• Robert Harvey: To figure out what Execute() and CanExecute() are actually executing, look at the concrete type that is being instantiated.

Answer 1

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.

• Robert Harvey: There's only one remaining useful case, and that is UI, even if it's just prefixing all of your control names with ux.
• Carcigenicate: @RobertHarvey Oh, honestly, I haven't done near enough UI stuff to know anything about that. Look up my submitted code review for a Game of Life clone. It's pretty sad lol.
• Jörg W Mittag: More precisely, this is the bad kind of Hungarian, the one which duplicates information. (Unlike the "slightly less bad kind", which encodes additional information in the name.)
• Carcigenicate: @RobertHarvey I just realized, wouldn't it more appropriate to just put UI related stuff in its own namespace?
• outis: @JörgWMittag: you're referring to systems v. apps Hungarian, correct?

Answer 2

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.

https://msdn.microsoft.com/en-us/library/4xhs4564(v=vs.71).aspx

• Robert Harvey: This isn't what the question is really about. The Exception suffix is well-established and well-known, and so are the conventions that the OP wants.

Answer 3

There are several interesting references that do recommend not to encode types within variable names:

• Uncle Bob's "Clean Code" recommends to avoid encodings (type, scope) in names, because they are a mental burden and not needed anymore with modern IDE and tools.
• Stroustrup, Sutter and al. also discourage these types of conventions in "C++ core guidelines" because they hinder evolution of code.

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.