Re: Language Choice and Coding style

[steidl@centuryinter.net]

In <31DEF0FC.4FDC@theriver.com>, "N. L. Sizemore" <bolshev@theriver.com> writes:
>steidl@centuryinter.net wrote (at end of very cogent argument):
>> 
>> Can someone come up with a case where:
>>    1. hungarian notation is needed for variables
>>    2. (1) is not solved by some other common good coding style method
>>    3. the case is not ultra-specific (i.e. it justifies hungarian
>>       notation as being a general good coding style method)
>
>	As a possible example meeting the stated desiderata I would offer certain types of transaction 
>processing code.  Assume:

OK, I'm not a DB man, so I'll state my assumptions about your assumptions
so that you can check to determine if my subsequent responses might be
totally from left field:

>	-	A three-tier c/s architecture

c/s == client/server (took me minute... like I said, Self != DB_programmer)
Is the client a tier, the server a tier, and the transaction
manager/monitor a tier inbetween?  [I am assuming that you are using a
three-tier architecture in your example because it necessitates your first
requirment below (i.e. local copies of data elements) in order to avoid
unnecessary RPCs).]

>	-	Control under a transaction monitor/manager

I assume this is for reliability (whole transaction completes or
doesn't complete) and logging purposes.  Or does it also allow/disallow
transactions to pass?  [I'm not sure what this assumption of yours
provides beyond your first one, so maybe I'm missing something here.]

>	-	A complex retrieval, i.e. , a data structure involving joins from several disparate data 
>sources
>	-	a (potentially) heavy transaction workload

At least know what those two mean. ;-)

>	-	Coding for transaction logic (aka 'business rules') at the 2nd tier, i.e., the transaction 
>server/router

Shoot, I know I've read about business rules somewhere...
something to do with coding company policy into your program I think.
[I can't remember exactly what this is, but I am assuming that the
reason you included this is because it would tend to make your
functions more complex.]

>	Under these assumptions reasonable code style requirements might include:
>
>	-	use local copies of data elements prior to 'prepare to commit'

I'm not sure how hungarian notation makes this any easier to do.
(My responses to your other two requirements may provide you with some
justification for this response of mine.)

>	-	avoidance of other than absolutely necessary context shifts, e.g., call/returns, RPCs, etc.

It may be necessary for the executable to be implemented using
large functions (and loop unrolling and tedious instruction
scheduling etc.) in order to be efficient, but that is no reason
that the programmer should be subjected to the same.  Luckily,
inline functions avoid the calls/returns without requiring us to
write huge functions (and thus lose the benefits of decomposition).

And the local copies of the data elements are already sufficient to
avoid unnecessary RPCs, right?

>	-	in line documentation of data types and/or sources which are defined externally

Well, I was only asking for hungarian use for variables, but
I totally ignored types in my original post - so here's my
opinion of them:  The whole reason a Type/Class is created is
to provide data abstraction of some kind.  The user should not
need to know what underlying built-in types the Type/Class is
composed of.  And since the user should not need to be at
all concerned with the underlying types, the Type/Class name
should certainly not carry around the baggage of hungarian
notation.

If by "sources" you are referring to source-code (functions), then
hungarian notation may be useful if your code editor does not have
a feature which lets you quickly examine the return type and
argument types.  (Although, including all of the argument types
for a procedure in some type of compound hungarian notation could
get quite lengthy - and would almost be a suitable replacement for
C++ name mangling, which isn't all that flatterring for hungarian
notation. :-)

>	An admittedly constrained example but not, I think, infeasible.


I think that what your above assumptions and requirements are defining
here is not limited to just database operations.  I think that you are
basically saying:
   "What if
      - My program includes certain expensive operations (such as RPCs)
        which are alleviated by having local copies of variables.
      - My program is large and complex.
      - My program needs to be efficient."

Welcome to the club! ;-)

Many programmers have to deal with this same set of obstacles.  So,
at least in that sense, your example really isn't all that constrained.
But I'm not able to see why it justifies hungarian notation.  Maybe
you could provide a more explicit correlation between your example
and the need for hungarian notation and/or correct any relevant
mistakes in my assumptions/responses.

I have given this subject a little more thought (hungarian notation
in general, not specifically in relation to your example), and have
come to a couple more conclusions.  First, I retract my opinion on
the use of hungarian notation for function names [I can do that,
check my .sig :-)].  I think that the paragraph which gives my
reasons for not using hungarian notation for types can be extended
to also cover variables and functions.  Well written code should not
only use the principle of abstraction for its types/classes (thus
removing the need for hungarian notation for types), but should
also apply this to its variables and functions.  For example, in some
code that I recently managed, I was very strict about the naming of
variables.  A client's record number was always stored in the
variable "ClientRecNum" (RecNum was one of the very few standard
abbreviations I allowed), or a variation on that (such as
"NewClientRecNum", etc.)  It did not matter whether the record number
was implemented as a signed int, or an unsigned long, that is not
relevant.  The variable's name can provide a level of abstraction just
as a data type can.  Note that I didn't allow the name "Client" for a
client's record number since that results in the variable appearing to
have a different "interface" than it actually did.  For the same reason
"ClientRec" was also not allowed.  And where a client record number was
actually the record number of the first client in a list of clients,
"ClientRecNum" was not allowed and instead "ClientList" was required.
I think if a variable accurately indicates what it is at the proper
level of abstraction, there is no need to prefix its name with the
underlying types.  It seems to me that doing so would only hurt the
maintainability of the code.


-Jeff

steidl@centuryinter.net - http://www.dont.i.wish.com/
All opinions are my own, and are subject to change without notice.