Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.help > #877

Re: Hungarian Notation and Java

From Travers Naran <tnaran@gmail.com>
Newsgroups comp.lang.java.help
Subject Re: Hungarian Notation and Java
Date 2011-07-17 22:06 -0700
Organization A noiseless patient Spider
Message-ID <j00evu$ggl$1@dont-email.me> (permalink)
References <b4d806bc-4f94-4655-8699-5e1c32e111ed@q1g2000vbj.googlegroups.com>

Show all headers | View raw


On 13/07/2011 7:46 AM, Steve wrote:
> Is there any reason left to use Hungarian notation with Java?

 From wikipedia's article on Hungarian notation:

"Microsoft has discouraged the use of Hungarian notation in the naming 
convention guidelines for .NET Framework, Microsoft's more recent 
software development platform, advising that Hungarian notation should 
not be used[8], although it was common on prior Microsoft development 
platforms like Visual Basic 6 and earlier."


But here's my advice on Hungarian (as said by people smarter than me):

Bjarne Stroustrup (against systems Hungarian for C++):

     "No I don't recommend 'Hungarian'. I regard 'Hungarian' (embedding 
an abbreviated version of a type in a variable name) a technique that 
can be useful in untyped languages, but is completely unsuitable for a 
language that supports generic programming and object-oriented 
programming—both of which emphasize selection of operations based on the 
type an arguments (known to the language or to the run-time support). In 
this case, 'building the type of an object into names' simply 
complicates and minimizes abstraction."[5]


Joel Spolsky (for apps Hungarian):

     "If you read Simonyi's paper closely, what he was getting at was 
the same kind of naming convention as I used in my example above where 
we decided that us meant "unsafe string" and s meant "safe string." 
They're both of type string. The compiler won't help you if you assign 
one to the other and Intellisense won't tell you bupkis. But they are 
semantically different. They need to be interpreted differently and 
treated differently and some kind of conversion function will need to be 
called if you assign one to the other or you will have a runtime bug. If 
you're lucky. There's still a tremendous amount of value to Apps 
Hungarian, in that it increases collocation in code, which makes the 
code easier to read, write, debug, and maintain, and, most importantly, 
it makes wrong code look wrong."[6]


In Java, the Apps Hungarian is a little useful, but as Lew said: a good 
name often makes it irrelevant.

For example, I _would_ use:

* dt, dx, dy = for delta values
* pointX, pointY = in this case, the "hungarian" is at the back for more 
natural reading.
* pixelX, pixelY = To emphasise the X, Y are in pixel-space.


I _don't_ use:

* rowAccount = I'd either just use Account (esp. if I'm using JPA) or 
accountRow
* usAccountName = "unsafe" account name passed in as a web parameter.  I 
would use unsafeAccountName so it's blatantly obvious, and the extra 4 
characters won't kill you.

Back to comp.lang.java.help | Previous | NextPrevious in thread | Find similar


Thread

Hungarian Notation and Java Steve <tinker123@gmail.com> - 2011-07-13 07:46 -0700
  Re: Hungarian Notation and Java lewbloch <lewbloch@gmail.com> - 2011-07-13 08:47 -0700
  Re: Hungarian Notation and Java markspace <-@.> - 2011-07-13 09:23 -0700
  Re: Hungarian Notation and Java Roedy Green <see_website@mindprod.com.invalid> - 2011-07-13 15:33 -0700
  Re: Hungarian Notation and Java Lothar Kimmeringer <news200709@kimmeringer.de> - 2011-07-14 18:45 +0200
    Re: Hungarian Notation and Java lewbloch <lewbloch@gmail.com> - 2011-07-14 17:30 -0700
  Re: Hungarian Notation and Java Travers Naran <tnaran@gmail.com> - 2011-07-17 22:06 -0700

csiph-web