From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,d95b511473b3a931 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,d95b511473b3a931 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,d95b511473b3a931 X-Google-Attributes: gid103376,public From: steidl@centuryinter.net Subject: Re: Language Choice and Coding style Date: 1996/07/08 Message-ID: <4rprlr$dhs@news.ld.centuryinter.net> X-Deja-AN: 167150037 references: <4re0la$qk6@news.ld.centuryinter.net> <31DEF0FC.4FDC@theriver.com> organization: Century Internet reply-to: steidl@centuryinter.net newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Date: 1996-07-08T00:00:00+00:00 List-Id: In <31DEF0FC.4FDC@theriver.com>, "N. L. Sizemore" 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.