Skip to main content
Printer-friendly version

Interestingly, while there are many who are opposed to Hungarian Notation, they will use aspects of it in their own code. E.g., there are a number of examples of this that have appeared in more recent code from PSC such as ttCustomer to indicate a Customer temp-table or qOrder in the code sample above. This is particularly notable in the series of whitepapers by John Sadd on the OpenEdge Reference Architecture (OERA) which includes examples such as eOrder (used for the “entity” or domain object temp-table), etOrder.i (the file containing the definition of eOrder, hBuffer (handle to Buffer), srcOrder (query and data-source for Order), sceOrder.p (file containing the data-source code), dsOrder (data set for Order), daOrder.i (include file with data access code for Order), daOrderValidate.p (procedure file with validation logic for Order), beEntity.p (procedure for business entity for Order), etc. Not all of these are variable names, of course, but the principle is the same. What is clear is that, while John Sadd has not adopted a universal notation for all variables and other names, that he has adopted and advocates a strong naming convention for a number of key elements of his formulation of OERA.

In a similar fashion, other PABL shops have adopted their own conventions over the years to provide special names for part of the overall nameset. Some of these are similar to the examples in the prior paragraph, e.g., hBuffer, and others are less clear, e.g., the old Varnet Order# and Order## to indicate secondary and tertiary buffers. One might suggest that all such naming conventions are an indication of the recognition of some virtue in a simple, standardized prefix or suffix naming system to identify names of a particular type or derivative names (as hBuffer is a handle to Buffer), but those adopting these conventions have declined such a standard universally.

While the current document is focused specifically on a particular prefix notation, it should be noted that the notion of standardized naming practices is a much broader issue of great importance. E.g., if one is going to adopt a Finder and Mapper object structure for data access, as will be described elsewhere, it is clearly poor practice to suddenly name something OrderGetter instead of OrderFinder, because significant information is lost. Similarly, if one has defined a type of Collection Class as SortedSet, then if one calls an object OrderSortedSet, it had better be an instance of that type of Collection Class.

This issue of information provided through standard naming practice lies at the heart of CI’s use of Hungarian Notation. One is faced with a choice of whether or not to provide potentially useful information as a part of a name and how to represent that information. E.g., in the case of a variable local to a method which is the character version of an order quantity for display purposes, one could include none of this context information and call the variable simply OrderQty, but then one might have a naming conflict with the integer version which is used for computation and persistence. One could, of course, call it OrderQtyChar or some such, but then, if the other variable is left as OrderQty, that doesn’t immediately identify what relationship it has to the longer name. Moreover, because one name is a subset of the other, one can have issues trying to do search and replace because the shorter form cannot be uniquely identified by some editors under some conditions. And, of course, neither lets one know whether the variable is local to a method or internal procedure, is a parameter, or anything about its presumed characteristics. Those associations can only be determined by searching for definitions and other references.

By contrast, simply calling these two variables mch_OrderQty and min_OrderQty, or whatever scope prefix is appropriate, conveys this contrast very compactly, consistently, and with facility for doing whatever one might need in search and replace. This, by the way, is one of the reasons for the convention of using a “tb_” prefix for database tables, which one might otherwise be tempted to leave unmodified, since it makes searching for them easy.

It is not expected that this short discussion will convince anyone with strong “anti-Hungarian” views to suddenly convert to using Hungarian Notation. It is hoped, however, that having some understanding of why people might choose to adopt this convention and its possible benefits will at least result in some tolerance of this “peculiarity” of the code we will be publishing.

The full current set of naming standards in use at CI follows. These standards have recently been updated to include prefixes appropriate to 10.1A and so may undergo additional revision with experience.

Next Page