I have read so many docs about naming conventions, most recommending both Pascal and Camel naming conventions. Well, I agree to this, it's ok. This might not be pleasing to some, but I am just trying to get your opinion on why you name your objects and classes in a certain way.

What happened to this type of naming conventions, and/or why are they bad?

I want to name a structure, and I prefix it with "struct". My reason is that, with IntelliSense, I see all structures in one place, and anywhere I see the struct prefix, I know it's a "struct":


another example is the enum, although I may not prefix it with "enum", but maybe with "enm":


again my reason is that in IntelliSense, I see all my enumerations in one place.

Because .NET has so many built-in data structures, I think this helps me do less searching. Note that I used .NET in this example, but I welcome language agnostic answers.


5 Answers 5


Joel wrote a good article on this

Making Wrong Code Look Wrong

In short, you want to use Apps Hungarian, not Systems Hungarian notation.

Because really, who cares if it's an int, or a long, or whatever, all I care about is the "kind" of value, not it's type.

  • 1
    Note that the use in the question is the version Joel (and pretty much everybody else) doesn't like. Nov 16, 2011 at 22:30

That is Hungarian notation. Its still used but much less so now in languages where the IDE helps you with types. (ie C# Java). In those langagues the information given by the prefix is already provided by the IDE so is deemed unnecessary.


The "type" of types shouldn't matter. class, struct, and enum are only meaninful to the definition - you shouldn't be using something differently just because it's a struct and not a class, nor should you refer to it as one.

I think the most sensible way to use "hungarian notation" is to only seperate types from functions:

  • types
  • instances of types
  • functions
  • Interface types and class types behave similarly in many contexts, but in some cases are semantically very different. Likewise struct instances and class instances. Further, the Char[] held by String has very different semantics from the the Char[] held by StringBuilder. I would posit that if things aren't the same, similarity among them often increases rather than decreases the likelihood of confusion in the absence of a naming convention.
    – supercat
    May 6, 2014 at 22:24

If the types have appropriate names in the application domain, then the underlying representation is not important. I much prefer code that reads like either prose or mathematics. In English we say "Post Office", not "officePost", so I prefer "EmailService" to "serviceEmail".


In object oriented programming languages, this "Systems Hungarian Notion" hardly has any place at all. Consider languages where everything is an object. You could rightfully use a prefix like "obj" for every variable, since everything is an object. But even if you use "int" and "dbl" for integer and double variables, what about the zillions of other objects? Would you invent a prefix for each and every class in your program and all the libs it uses? Or would you use a completely meaningless prefix like "obj"? Neither option makes much sense.

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