wood burning stoves 2.0*
The moose likes Java in General and the fly likes Hungarian notation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Hungarian notation" Watch "Hungarian notation" New topic
Author

Hungarian notation

Tibor Kiss
Greenhorn

Joined: Feb 21, 2000
Posts: 2
Anyone could explain why Hungarian notation violates OO abstraction?
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
There's several articles here already on this. Try a search for Hungarian.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20489
    ∞

Check out http://www.javaranch.com/ubb/Forum19/HTML/000026.html

permaculture Wood Burning Stoves 2.0 - 4-DVD set
Dave Brookes
Greenhorn

Joined: Feb 23, 2000
Posts: 17
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


Regards,<br />Dave
Tibor Kiss
Greenhorn

Joined: Feb 21, 2000
Posts: 2
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

Joined: Dec 14, 1998
Posts: 20489
    ∞

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

Joined: Feb 23, 2000
Posts: 17
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

Joined: Jan 20, 2000
Posts: 33
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.

<B>Rich Wardwell</B><BR> <A HREF="mailto:rcw3@levelpath.com" rel="nofollow">rcw3@levelpath.com</A> <BR>Sun Certified Programmer for the Java 2 Platform
Dave Brookes
Greenhorn

Joined: Feb 23, 2000
Posts: 17
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

Joined: Jan 07, 1999
Posts: 6920
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

Joined: Feb 23, 2000
Posts: 17
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.
 
 
subject: Hungarian notation
 
Similar Threads
Hungarian notation
Hungarian Notation is a no no
Change 2 if conditions into 1 if condition ?
Hungarian Notation
What is Hungarian notation?