Hungarian names, space travel and Martha Stewart

If you looked at the blog called Variable Names you know that I am not a fan of the Comet / Qantel notion of using the same name for variables in different data files. The classic examples are Customer Number and Order Number. These two variables appear ALL over a Solutions based accounting system. The Order Number is created in Order Entry but it flows into the Order (Header) File and into all the ancillary files that comprise the Order File. It appears in the Order Detail file, as well as in all the many pointer files that drive the order processing system. In all these files, and in many others, the Order Number is not only a field in the file, it usually is the part or all of the key of the file.

I'm here to say that each of these Order Numbers should have a unique name. When a program references order number it should be immediately clear which order number is meant. So, how to come up with meaningful names?

Really smart programmers have given this some thought. We're not the first ones to worry about how to name variables. Microsoft has a scheme it uses that the folks there call Hungarian.

If you follow the link, you'll see that Hungarian is not Polish! Simonyi's scheme requires putting a prefix on the real variable name and that prefix tells the coder something about the characteristics of the variable. In the C language family the type of variable - integer, boolean, floating point - is really important; there are lots and lots of rules about using and converting data from one data type to another data type.

We don't have the luxury (or the burden) of dealing with different data types. In IB there are really only two data types: strings and numbers. Of course, we often create our own sub-data types: arrays, dates, edit masks, strings that are really numbers, and more. Our programs only work properly when we keep these different formats clearly in mind. Despite the importance of data type, I really believe that the biggest source of confusion in IB programming is knowing the origin of each variable.

Is this the customer number from the customer master or the customer number from the order file? Is this the running balance accumulated as the program runs or is this the balance in the just read order file?

I am proposing that we append the file name as a prefix to the base variable name. So the Order Number in the Order Header would be o1aOrnbr$ while o1Ornbr$ is the variable in the Order Detail file.

I know. I know. Why not O1A.Ornbr$? Because UltraEdit does not like embedded periods. As nice as dots may be, and even if Brian pointed the way, names like cosNMHDR.LENGTH just don't agree with UltraEdit.

oh yea, I promised you outer space. OK here it is. And Martha Stewart. And I know that Martha would approve of a nice, neat orderly naming convention.