2

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":

structPerson
structPosition

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

enmFruits
enmSex

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.

Jalayn
  • 9,789
  • 4
  • 39
  • 58
Smith
  • 643
  • 5
  • 14
  • 5
    This type of notation is known as Systems Hungarian notation: http://en.wikipedia.org/wiki/Hungarian_notation#Systems_vs._Apps_Hungarian – Zach Nov 16 '11 at 22:21
  • 1
    Possible duplicate: http://programmers.stackexchange.com/q/79024/15464 – Steven Jeuris Nov 16 '11 at 22:34
  • 1
    See: http://programmers.stackexchange.com/questions/102689/what-is-the-benefit-of-not-using-hungarian-notation – Marjan Venema Nov 17 '11 at 07:22
  • I had the same "what happened to Hungarian?" question too. I [wrote-up my findings and considerations here](http://reconvolution.blogspot.com/2014/07/what-happened-to-hungarian-notation.html). – Nick Alexeev Jan 07 '15 at 22:50

5 Answers5

10

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.

CaffGeek
  • 8,033
  • 5
  • 32
  • 38
4

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.

Tom Squires
  • 17,695
  • 11
  • 67
  • 88
2

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
Pubby
  • 3,290
  • 1
  • 21
  • 26
  • 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 06 '14 at 22:24
2

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

kevin cline
  • 33,608
  • 3
  • 71
  • 142
1

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.

user281377
  • 28,352
  • 5
  • 75
  • 130