Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
5  
This type of notation is known as Systems Hungarian notation: en.wikipedia.org/wiki/… –  Zach Nov 16 '11 at 22:21
    
Possible duplicate: programmers.stackexchange.com/q/79024/15464 –  Steven Jeuris Nov 16 '11 at 22:34
    

5 Answers 5

up vote 11 down vote accepted

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.

share|improve this answer
1  
Note that the use in the question is the version Joel (and pretty much everybody else) doesn't like. –  David Thornley Nov 16 '11 at 22:30

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.

share|improve this answer

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

share|improve this answer

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
share|improve this answer
    
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 at 22:24

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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