On 25 May 2001, at 8:30, Patrick McElhaney wrote:
> I think Hungarian Notation is a workaround for
> poor programming practices.
The code shops I know that use HN are among the best practitioners you'll find.
I suggest that if you make statements like this you should stay out of dark
alleys.
> 1) Code is not properly modularized.
> If you only have to work with a handful of variables
> at a time, it's much easier to keep track of them.
> (This is especially true in a typed enviornment
> where the variable's declaration is not far from
> the place where it's being used.)
Hmmm. Let's see--if you declare a custom data type in VB, let's say, then the
definition is rarely in the same module to where it's being used. And you
CAN'T by definition declare it twice. Scrap complaint #1.
> 2) Nondescript variable names.
> "intItems" (and especially "iItems") isn't much
> more meaningful to me than "items", but
> "numberOfItems" tells me exactly what the
> variable represents, and the fact that it's
> an integer can be inferred.
A time-and-materials system bills for parts purchased or labor spent. Items
might be counted in whole (parts) or in part (hours or fractions thereof). A
name like "numberOfItems" lends no inference whatsoever here.
"sngNumberOfItems", OTOH, tells you exactly what you're dealing with. If your
db guys use a prefix standard for field names as well, you can easily check
your assumptions when you're writing SQL. Scrap complaint #2.
> 3) Little or no documentation.
> One comment and the type is documented for every
> single use. Isn't that preferable to documenting
> the type every single time you use the variable?
> If you're using fusedocs (and you should be) it's
> already taken care of.
The point of HN *is* to assist documentation. Fusedocs help a great deal, and
mostly obviate the need for an HN-style practice in our environment. However,
I find that the more information I give my coders (and they give each other) as
we work, the better work we do, and the more efficient we are. Using an HN-
type convention also drills the type into the coder's awareness, so there's a
reduced tendency to spend time resolving questions about what kind of data we
might be receiving. Even though CF is typeless, a thorough understanding of
the assumptions behind the process can only help. Scrap complaint #3.
The fact of the matter is, HN (or conventions like it) are designed to assist
best practices in team coding shops. If you work all by yourself and do the
whole system, HN may appear to have little benefit. (But it will certainly
help you pick up an old project that you haven't looked at in a while.)
So, if you're a loner, I can understand your contempt. If you're a team
leader, I sure hope you hire clairvoyant coders.
- Jeff
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
