Skip to main content
Printer-friendly version

Hungarian Notation is often associated with the use of “CamelCase”, i.e., mixed upper and lower letters to assist in identifying multiple words in a name, although there are many people who use CamelCase without advocating Hungarian Notation. Classic Hungarian Notation places the prefix in lower case immediately on the front of the word, e.g., chFirstName. CI’s formalization utilizes a separating underscore to make the name and the type more readily distinguishable, e.g., ctt_Invoices and chn_Invoices.

Note that since this document was written, I have been experimenting with omitting the underscore and I seem to prefer this, but otherwise the principles suggested here continue to be used

Arguments against the use of Hungarian Notation usually focus on the question of readability. While this has some point in extreme cases such as the one quoted above, that example merely illustrates that any convention can be abused. Much of the issue of readability depends on what one is used to. For example, Progress Software has historically used upper case for keywords. This is convenient when referring to isolated keywords in text, such as “OPEN QUERY”, because it makes it clear that the words are “special”, but in the context of code, there are many who feel that one is giving emphasis to the wrong part of the code, as if the keywords were shouting. For example, this fragment from the 10.1A 4GL Reference Manual, is shown there as:

DEFINE QUERY q-order FOR
    customer FIELDS (customer.cust-num customer.name customer.phone),
    order FIELDS (order.order-num order.order-date),
    order-line FIELDS (order-line.line-num order-line.price order-line.qty),
    item FIELDS (item.item-num item.item-name item.cat-desc).
OPEN QUERY q-order FOR EACH customer,
    EACH order OF customer,
    EACH order-line OF order,
    EACH item OF order-line NO-LOCK.

Converting this to lower case keywords, camel case names, no hyphens, but no Hungarian prefixes except the ones already in the PSC example, produces:

define query qOrder for
    Customer fields ( Customer.CustNum Customer.Name Customer.Phone ),
    Order fields ( Order.OrderNum Order.OrderDate ),
    OrderLine fields ( OrderLine.LineNum OrderLine.Price OrderLine.Qty ),
    Item fields ( Item.ItemNum Item.ItemName Item.CatDesc ).
open query qOrder for each Customer,
    each Order of Customer,
    each OrderLine OF Order,
    each Item of OrderLine no-lock.

The contrast is hardly dramatic, but has the effect of making the table and field names more prominent than the ABL keywords. Now lets add the type of Hungarian Notation used by CI:

define query lqu_Order for
    tb_Customer fields ( tb_Customer.ch_CustNum tb_Customer.ch_Name tb_Customer.ch_Phone ),
    tb_Order fields ( tb_Order.in_OrderNum tb_Order.da_OrderDate ),
    tb_OrderLine fields ( tb_OrderLine.in_LineNum tb_OrderLine.de_Price tb_OrderLine.in_Qty ),
    tb_Item fields ( tb_Item.in_ItemNum tb_Item.ch_ItemName tb_Item.ch_CatDesc ).
open query qu_Order for each tb_Customer,
    each tb_Order of tb_Customer,
    each tb_OrderLine OF tb_Order,
    each tb_Item of tb_OrderLine no-lock.

Note that in this example, all references are to table or field names and therefore the scope component is considered meaningless and thus is missing. If one is unused to reading Hungarian Notation, the initial reaction is likely to be that this is less readable than the prior example, but consider the additional information provided. We know, for example, that the query is local to a procedure and that all of the tables and fields are from the database. Suppose, for example, some or all of the “tb_” prefixes where replaced with “ltt_” prefixes; then we would know that we were dealing with local temp-tables rather than database tables. Or perhaps an “mtt_” prefix telling us that the temp-table was local to a method. This is significant additional information that is otherwise not available without reading additional code.

Next Page