Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Hungarian notation

 
Tibor Kiss
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anyone could explain why Hungarian notation violates OO abstraction?
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There's several articles here already on this. Try a search for Hungarian.
 
paul wheaton
Trailboss
Pie
Posts: 21468
Firefox Browser IntelliJ IDE Java
 
Dave Brookes
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just another view for balance...
We used a variant of hungarian notation successfully as a standard for coding SCL (on ICL VME mainframes) for many years. When I started learning Java I found it both natural and useful to continue to do so. I restrict its use to the primitive data types, with the added advantage that it distinguishes between object references and the primitives.
For example:
int i_amount - for a primitive int but
Integer amount for an associated object wrapper.
Anytime these are referenced I know instantly what I'm dealing with.
------------------
Regards,
Dave
 
Tibor Kiss
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I never used HN with all of my variables. I still think, that using HN can make code more readable. (Of course, I never intended to use it for object references, only for primitive types, eg.: int iCounter.)
I have been programming Windows extensively, and if you have a look at the MFC source code, it would be more messy without HN.
 
paul wheaton
Trailboss
Pie
Posts: 21468
Firefox Browser IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One of the cornerstones of OO is abstraction. You have an identifier that will contain information for you. It may be an int, or a double or an object reference. The key is that for most of your use of that identifier, you should theoretically not care as long is it will hold your value and give the same value back when you ask for it. At some later time, you might change your double to a float. Or change your int to a long and all of your program will continue to work fine (okay, you will probably have to do some casting here and there now). This is abstraction.
HN takes away this abstraction. HN also adds a responsibility to the developer that if they change the type of something, they must go to every instance and change the identifier. I suspect that some developers will choose to change the type without changing the identifier and now the code has become much less readable.
Finally, HN is not a standard in Java. It is very rare. I think I've seen it just once. I think we all benefit if we stick to standards that at least 40% of the Java community is doing.
I feel strongly enough about this that if I worked for a company where management announced that HN would be the company standard, I would quit. I only want to be involved with modern, high quality engineering practices and using HN with OO isn't.

 
Dave Brookes
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Paul's view that the use of HN, even if restricted to primitive data types, does reduce abstraction.
But why does abstraction matter? Just like using HN, its role is that of enabling maintenance. In the age of universal provision of find/replace, in even basic programmer editors, the overhead of changing all occurrences is pretty low. What matters more, when 'programming in the large', is how quickly I can understand the code, usually in order to fix it!
Given that changing data types is not without other considerations, particularly if narrowing the cast, most developers would choose to review how the variable is being used anyhow.
On balance I'm happy to knowingly sacrifice a little abstraction in support of maintainability.

------------------
Regards,
Dave
 
Rich Wardwell
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmmm... abstraction is the holy grail of component based system design IMO. As far as readability, abstraction is the only design technique that will allow someone to truly get their hands around a large project - not notating a few variables. Most of the real "readability" issues is not figuring out what a variable is or does but trying to figure out the interface of an object and how it relates and interacts with a bunch of other objects to produce some result. Without abstraction, this can become a tedious and difficult task, and when you do finally figure it out, you can forget about extending or modifying the code without breaking all kinds of interdependencies.
 
Dave Brookes
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
16 years of fixing others code makes you appreciate a whole raft of conflicting concepts that ease the task!
However, as soon as the debate moves away from primitive data type notation then I'm fully back in the fold with the desire to encourage and protect abstraction. Seems to me that abstract class design is the only way to partition a complex requirement and hopefully generate a worthwhile degree of reuse.
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave Brookes wrote:
In the age of universal provision of find/replace, in even basic programmer editors, the overhead of changing all occurrences is pretty low.
I recall a similar discussion on another board, in this case more specifically about refactoring and the potential benefit of a "refactoring browser" which understands the structure of code and allows most refactorings (such as changing the name of a method) to be "one-click" operations. One correspondent asked essentially the same question as above.
The answer was pretty simple. Would you really trust a global find/replace to change, for example "iCount" to "lCount" without accidentally changing other matching patterns such as "iCount" in another scope, "iCounter", or even "DeliCounter" at the same time. To be 100% confident of automatic find/replace, all your names have to be entirely separate, which seems a mad overhead to require.
The other problem is that for method parameters and return types only the type is known, not the names of variables in other scopes which use it. And in many cases the parameters aren't even variables, but expressions or casts. Can you provide a find/replace pattern which would successfully transform even the following simple case from using ints to floats:

For me the bottom line is that any form of markup which does not directly reflect the problem domain is a candidate for removal, and may just make more work for a maintainer.
I much prefer to refactor code into small enough chunks so that the definition of any local variable is only an eye-flick away, and name interface methods and instance variables by domain function.
 
Dave Brookes
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But Dave Brookes also wrote:
-------------
Given that changing data types is not without other considerations, particularly if narrowing the cast, most developers would choose to review how the variable is being used anyhow..
-------------
So no, I would not use the Find/Replace function in the situation described by Frank; but Find and Find next would be useful.
Surely the real point here is that even the use of an abstract variable name still requires the self same care, particularly in the scenario provided by Frank where the requirement itself is changing (i.e. the change of precision). I understand that it was reuse without ensuring that the implementation detail actually matched the newly required precision that led to Arianne4 software malfunctioning when reused for Arianne 5... with expensive consequences.
That said I do see the logic / value of the abstract variable approach and would be equally happy to adopt it, but without seeing it as a panacea.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic