> > 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.
Do you use HN with custom types? If so, how do you have a
"standard" notation? I know the definition of the custom type
won't be in the same module, but won't the variable still be
declared in the same module?
> > 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.
I would never look at a variable called "sngNumberOfItems" and
think that it represents units of time.
> > 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.
I agree 100%. Does HN give your coders more information?
> 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.)
The main reason I don't like HN is because I've had such awful
experiences working with code that was written by others using HN. Of
course, that code was pretty bad off to begin with. HN seems to make
ugly code uglier.
Patrick
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
