🚀 go-pugleaf

nevin@dtint.dtint.com writes:
>I've been the route of extremely strict conventions (see Charles  
>Symoni, MIT/Microsoft on type naming calculus commonly referred to as  
>"Hungarian"), and I find the middle ground more appealing (i.e. a  
>'relaxed' but enforceable, democratic group of standards).

I use a Hungarian style similar to Symoni's. It was forced upon me against
my will a few years back. Now, it seems to me to be a necessity. There are
several concrete advantages, some of which are:

1) Simpler semantics checking. You rely a *lot* less on your memory of
what kind of thing a variable represents. Multi-level pointers become
tractable. Mismatches between declaration and usage are visually apparent.
Related entities are clearly related by similarity of names.

2) Uniformity across a project. People tend to choose the same names for
the same things, even when they aren't communicating.

3) Name formation becomes much more mechanical. You can stop spending all
day looking for good names for your variables, and expend your creativity
in more valuable ways.

4) Simpler, more reliable global search-and-replace. With the right set of
naming rules, you can make some really scary name changes safely, and not
take all day to do it.

5) Code from code generators is more easily read by humans.

One of the greatest advances of the Industrial Revolutions was the idea
of standardized, interchangeable parts. Object programming does this at
a high level, Hungarian does it at a low level. Both matter.

If anybody out there hasn't seen this stuff and is interested, send e-mail.

Steve abell@netcom.com