File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Java ranch style quide question 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 » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Java ranch style quide question" Watch "Java ranch style quide question" New topic
Author

Java ranch style quide question

Wendy Gibbons
Bartender

Joined: Oct 21, 2008
Posts: 1107

i was reading the java ranch code style guide (http://www.javaranch.com/styleLong.jsp#inc) and found this statement which i didn't understand:

Reasoning: Hungarian Notation, which specifies type as part of the identifier, violates OO abstraction. Scope identification specifies scope as part of the identifier, which also violates OO abstraction.


with this example:

can anyone explain it further please?
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

Why do you think that more explanation is needed?

Or to put it another way, what is missing from the explanation already provided?
Wendy Gibbons
Bartender

Joined: Oct 21, 2008
Posts: 1107

in which way is including this information in variable names breaking abstraction, as none of this information will make it outside the interface/ getters.
(before anyone berates me i don't actually do it, but only because eclipse means I have no need to)
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4340
    
    2

i remember having to use that hungarian notation in a VB class. i didn't really like it. on the other hand i often write stuff like
private Image image;
private File file;
i not only specify type as part of the name but as the whole name. i fail to see the problem. it cannot be confused with the class(at least it doesn't confuse me). i mean what else are you gonna call them?

oh, and thanks for the link. i have been looking for something like that.


SCJP
Visit my download page
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

Wendy Gibbons wrote:in which way is including this information in variable names breaking abstraction, as none of this information will make it outside the interface/ getters.


That's a good question. I read through the Wikipedia article at http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29, including especially the sections headed "Data abstraction" and "Abstraction in object oriented programming". The best I could come up with was this:
Data abstraction enforces a clear separation between the abstract properties of a data type and the concrete details of its implementation.


But even so, it's a stretch to suggest that the name of a variable is a concrete detail of its implementation. And encapsulation isn't affected, since the variable-name prefixes are only duplicating information which is already visible to the users of the variable (which is your point, I believe). So basically I can't find any support for the statement.

The Hungarian notation does violate the DRY principle, though.

Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3582
    
  14

The name should not say anything about its data type, because it may change in a future version of the code. While it's unlikely that a String will ever stop being a String, something that was once a list may in a future version be replaced with a tree.

Let's say we have a String that represents a phone number. We call it sPhoneNumber. What if somebody writes a really awesome PhoneNumber class that works universally, and it gets included in the standard API? If we refactor our code, we have all these variables with an s in front of it, which really doesn't make sense any more. This should be enough illustration to show you that a data type is not part of a variable name, and never should be.

In Randall's example, file and image are named because that's what the variables conceptually represent. The fact that the data type's name happens to have the same name should be considered coincidence. If the data type for path names was called Q12Fah8, the variable would still be called file, because that's what it represents. (Actually it doesn't, it represents a path name, not a file. The API designers also realized this mistake and obsoleted the File class in favor of the Path class).
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4343
    
    8

Stephan van Hulst wrote:Let's say we have a String that represents a phone number. We call it sPhoneNumber. What if somebody writes a really awesome PhoneNumber class that works universally, and it gets included in the standard API? If we refactor our code, we have all these variables with an s in front of it, which really doesn't make sense any more. This should be enough illustration to show you that a data type is not part of a variable name, and never should be

But in that case the change of variable name will be one (relatively trivial) part of the refactoring required.

I don't like the practice either. I especially don't like it when I see database table names prefixed with "tbl" - "yes, I can tell from context that it's a table - tell me something useful". I'm just not 100% convinced by that particular argument. My main issue with Hungarian notation is that, especially with modern IDEs, they add no value, and so just are just noise obscuring the actual meaning of the variable.
Tim Moores
Rancher

Joined: Sep 21, 2011
Posts: 2408
I'd agree that Hungarian Nototian was most useful for C/C++ which was not really strongly typed. It should be noted that there were two different forms of the notation which specified different things of different usefulness; some detail about that can be found at http://www.joelonsoftware.com/articles/Wrong.html
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1006
    
    3
Tim Moores wrote:I'd agree that Hungarian Nototian was most useful for C/C++ which was not really strongly typed. It should be noted that there were two different forms of the notation which specified different things of different usefulness; some detail about that can be found at http://www.joelonsoftware.com/articles/Wrong.html


Thank you for the pointer to that article. I was one of the programmers who only ever heard of "Systems Hungarian", which, as the article points out and is being argued here, is pretty much useless. The Apps Hungarian is indeed much more useful. I would argue that using such a notation would NOT violate the OO principles mentioned by the OP.

e.g.
private String sFirstName; // NO! s for String is a bad thing.
private String usFirstName; // A little better I suppose. It still includes the String-iness of the variable in the name, but it includes the "unsafe" attribute of the variable.
private String ueFirstName; // Better still. Here, I made up the prefix "ue" to stand for User Entered. It denotes that this String contains exactly what the user typed into a form, without any encoding.

ueFirstName could be changed to some other type (StringBuffer perhaps) without the need to rename the variable.

Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4340
    
    2

i tend to agree with Tim. the notation was developed for languages that are not strongly typed like java is. i remember in the early early days when all most of us had was some proprietary Basic, and very little memory. i used to structure my basic programs so letters at the beginning of the alphabet(a,b,c) were global variables. ones in the middle(i,j,k) were loop variables. and ones at the end(x.y.z) were temporary variables that could be reassigned when they were no longer needed. i miss the old days a little, but i like descriptive variable names.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15952
    
  19

Actually, what brief love I did have for Hungarian notation died when I was most heavily involved with C++, precisely because of the data typing. Just because you can freely cast in C/C++ doesn't mean that they aren't strongly-typed.

But I got fed up with names that lied as their underlying datatypes shifted from integers to iterators to strings and back as I tweaked class details and threw up my hands over the whole concept.


Customer surveys are for companies who didn't pay proper attention to begin with.
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1006
    
    3
Tim Holloway wrote:Actually, what brief love I did have for Hungarian notation died when I was most heavily involved with C++, precisely because of the data typing. Just because you can freely cast in C/C++ doesn't mean that they aren't strongly-typed.

But I got fed up with names that lied as their underlying datatypes shifted from integers to iterators to strings and back as I tweaked class details and threw up my hands over the whole concept.


Go back and read the linked article: http://www.joelonsoftware.com/articles/Wrong.html

As originally developed... "Apps" Hungarian Notation does not prefix variable names with their underlying type, but rather with the kind of data they're holding. e.g. A variable prefixed with xw is an x coordinate relative to a window and yw is a y coord relative to the window. Two variable might have the exact same underlying types but different prefixes. If you ever see xwAbc = ywPqr, the line is worth looking at even though the underlying types are the same. (There might be reasons for assigning a yw value to an xw variable, but such an assignment is a mistake often enough that you should stop and look at what the code is trying to do.)

On the other side of the coin, you can change the underlying type of all xw and yw variables from int to long without the issue of misleading variable names.

It wasn't until someone misinterpreted the original intent of the notation and started prefixing variables with their underlying types (i.e. Systems Hungarian Notation) that the problems started. Firstly, it doesn't make obvious the kind of value each variable is used for. The x-coord = y-coord example above would look like this: iAbc = iPqr. There's no indication that we're assigning an y coordinate value to an x coordinate variable. And secondly, if you change the underlying type of those variables, you either have to rename the vars PLUS all the other variables, method parameters, constants, etc. that are related, or you have to put up with variable named something like iAbc being of type long.

Unfortunately many people were turned off to "Hungarian Notation" because of the problems with the Systems variant and never realized that the perfectly sane original "Apps" version was available.

Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60774
    
  65

Meh, I don't like either variant. Just makes for messy-looking names. Good choice of names in the first place should make it clear what the variable is representing. Just my 2¢.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1006
    
    3
Bear Bibeault wrote:Meh, I don't like either variant. Just makes for messy-looking names. Good choice of names in the first place should make it clear what the variable is representing. Just my 2¢.


One man's "messy" is another's "concise".

xwSubmitButton versus submitButtonHorizontalOffsetRelativeToCurrentWindowViewport. (...intending the hyperbole to be obvious.)

Also, the "good" Hungarian Notation is an attempt at one element of good choice of names in the first place to make it clear what the variable is representing. I should hope that users that chose to use HN would follow-up that reasonable initial decision with the use of variable names like xwUserName and ywPassword when laying out a form, rather than taking the first step but then using otherwise meaningless variable names like xw1 and yw2.

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Java ranch style quide question
 
Similar Threads
Hungarian notation
Hungarian notation
Style Guide
Is String s = args[0] Hungarian notation?
OO abstraction