Your point #1 is not a problem with hungarian notation. It's a
problem with a sloppy programmer. There's no convention that can
fix this sort of problem.
Point #2 is quite correct. It's only a convention unenforced by
the compiler which is the root of the problem anyway. As long as
compilers let you name variables any way you like and allow you
to mismatch types which cause the program cough up its socks at
runtime, then that's a weakness in the programming environment.
For me, using Hungarian notation is primarily a defensive
programming technique and has proved its worth more often than
not.
Point 3, 4, and 5 are sort of related. Hungarian notation can
lead to long names, and though there is an argument to be made
for going "all the way" and applying it to function names, type
members, etc. you can take a good idea too far. I tend to use
hungarian notation a great deal, but often I also use the earlier
convention of reserving certain variables for basic counters and
indexes, e.g. i, j, k, m, and n with p and c as pointers into and
to character strings. But these are used only in tightly defined
contexts where the declarations are in close proximity to the
variables and the variables are local to the subroutine (your
point #6).
Along with that, you don't have to have individual prefixes for
everything. For instance you could use 'sty' for all style
variables instead of breaking out each as 'pen', 'brush', 'sym'
or 'font' but I would only do that in cases where I don't need to
manipulate the contents of these. In Windows there's a lot of
handle types to work with by but often all I need to do with them
is pass them back and forth, so 'h' is a good enough prefix for
most of those types.
In the end, it's just a convention designed to compensate for
weaknesses in the programming environment, and is on a par with
indenting rules, commenting detail, etc. To one who isn't used to
it, another's convention (especially when it isn't perfectly
consistent) can be as opaque as any spaghetti code, but once you
adopt a convention and use it consistently, code reliability goes
up and stupid mistakes go down. There are plenty of *grand mal*
mistakes you can make once you leave the little ones behind!
Especially with MapBasic where the only editor more primitive is
edlin.
--
- Bill Thoen
------------------------------------------------------------
GISnet, 1401 Walnut St., Suite C, Boulder, CO 80302
tel: 303-786-9961, fax: 303-443-4856
mailto:[EMAIL PROTECTED], http://www.gisnet.com/
------------------------------------------------------------
"Warren Vick, Europa Technologies Ltd." wrote:
>
> Personally, I'm not a fan of Hungarian notation. I've taken this view
> over the course of many years with projects where I have started with,
> or later maintained, code using it. I think Hungarian notation
> originated from languages where a data type is not explicitly declared
> by is inherent from the start of the variable name. Needless to say,
> this trend did not get followed in modern languages. In the Windows
> environment, Microsoft then became quite keen on it and use it in API's
> to date.
>
> In theory, the notation should work because it is a form of
> documentation that in embedded into the code. It does however, have some
> practical drawbacks:
>
> 1) When a variable changes type (and that happens a lot), a developer
> should change the variable name. In many cases they don't, and it causes
> all sorts of problems. Even Microsoft were guilty of this when the Win16
> APIs were changed to Win32. All word based (w prefix) should have been
> changed to Double words (dw prefix) but some slipped through the net. Of
> course it can be argued that is strict code change practices are adhered
> to, this problem will not happen... but it usually does.
>
> 2) It's important to remember that it is only a commenting convention -
> you get no extra warnings or errors from compilers and interpreters.
>
> 3) How far do you go? Should you prefix function names?
>
> 4) Although not so much a problem with MapBasic given it's basic and map
> types, richer environments give rise to some really ugly variable names.
>
> 5) A VB programmer once told me there were well over 100 data type
> prefixes for the language!
>
> 6) It can be argued that in well designed/written code, the definition
> is never that far away from the use. Localised variables, keep functions
> to a manageable length, avoid globals, etc. Some development
> environments tell you what a variable is just by hovering the mouse
> pointer over the name.
>
> 7) A lot of developers who ported software from Win16 to Win32 grew to
> hate Hungarian notation. Just wait until we step up, or across, again.
>
> 8) Again, away from MapBasic, there is a strong argument that it's not
> necessary with OO languages. Some argue that C++ doesn't fall into this
> category due to its heritage.
>
> 9) I concede that I do prefix class types with "C", but this is slightly
> different from variable use and does help with preventing namespace
> contamination.
>
> This is just my opinion - there's no right or wrong. Do what you need,
> or are forced, to do!
>
> Regards,
> emhWarren_Vick (emh = English Male Human)
> Europa Technologies Ltd, U.K.
> http://www.europa-tech.com
>
~~~~~~~~~~ Advertisement ~~~~~~~~~~~
Quick DOQQ Aerial Photos - Lower Price, Faster Delivery
LAND INFO offers full coverage of DOQQ aerial photos, priced lower and
delivered faster than the USGS and other providers. LAND INFO also offers
feature extraction from the photography. Visit
http://www.landinfo.com/directions.htm for complete details.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________________________________
List hosting provided by Directions Magazine | www.directionsmag.com |
To unsubscribe, send e-mail to [EMAIL PROTECTED] and
put "unsubscribe MapInfo-L" in the message body.
