Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.help > #877
| 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> |
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 | Next — Previous in thread | Find similar
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