Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Java ranch style quide question

 
Wendy Gibbons
Bartender
Posts: 1111
Eclipse IDE Oracle VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 21298
32
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1111
Eclipse IDE Oracle VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4467
3
Java Python Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Paul Clapham
Sheriff
Posts: 21298
32
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 6081
71
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4568
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 2893
46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1072
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4467
3
Java Python Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 18272
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ryan McGuire
Ranch Hand
Posts: 1072
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 65105
89
IntelliJ IDE Java jQuery Mac Mac OS X
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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¢.
 
Ryan McGuire
Ranch Hand
Posts: 1072
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic