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

  • 1
    To figure out what Execute() and CanExecute() are actually executing, look at the concrete type that is being instantiated. Commented Jul 29, 2016 at 20:13

3 Answers 3


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.

  • There's only one remaining useful case, and that is UI, even if it's just prefixing all of your control names with ux. Commented Jul 30, 2016 at 0:19
  • @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. Commented Jul 30, 2016 at 0:46
  • 2
    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.) Commented Jul 30, 2016 at 1:24
  • @RobertHarvey I just realized, wouldn't it more appropriate to just put UI related stuff in its own namespace? Commented Jul 30, 2016 at 1:25
  • @JörgWMittag: you're referring to systems v. apps Hungarian, correct?
    – outis
    Commented Jul 30, 2016 at 9:28

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.


  • 2
    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. Commented Jul 29, 2016 at 20:09

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.