Quote:Original post by Anonymous Poster
Quote:Original post by Oluseyi
Prefixes should indicate use, not type. Ironically, this was Simonyi's original intention with what is popularly known as "Hungarian Notation"...
Do we have to go through this again? I posted a response to this exact same comment back in July, showing that Simonyi's intention must have been TYPE, not usage.
This goes directly contrary to what Simonyi says in the article:
Quote:
As suggested above, the concept of "type" in this context is determined by the set of operations that can be applied to a quantity. The test for type equivalence is simple: could the same set of operations be meaningfully applied to the quantities in questions? If so, the types are thought to be the same. If there are operations that apply to a quantity in exclusion of others, the type of the quantity is different.
The concept of "operation" is considered quite generally here; "being the subscript of array A" or "being the second parameter of procedure Position" are operations on quantity x (and A or Position as well). The point is that "integers" x and y are not of the same type if Position (x,y) is legal but Position (y,x) is nonsensical. Here we can also sense how the concepts of type and name merge: x is so named because it is an x-coordinate, and it seems that its type is also an x-coordinate. Most programmers probably would have named such a quantity x. In this instance, the conventions merely codify and clarify what has been widespread programming practice.
Note that the above definition of type (which, incidentally, is suggested by languages such as SIMULA and Smalltalk) is a superset of the more common definition, which takes only the quantity's representation into account. Naturally, if the representations of x and y are different, there will exist some operations that could be applied to x but not y, or the reverse.
I think this makes Simonyi's intention quite clear: HN codes for the operations which can be performed upon the object. Necessarily, this is a subset of the operations which the compiler will allow to be performed, and the compiler will only allow an operation to be performed upon an object if the object is of a suitable 'compiler type'.
Further examination of the code snippet is informative. Although compiler types are coded within the names of many variables, not all of them code for the type
of that variable, but of a related variable.
rgwDic Array of words used as a dictionary. There's no way to tell from "int*" if the variable is to be thought of as pointing at an array of objects or a single object, thus 'rg' is not coding for compiler type. 'w' might be coding for compiler type, though.
bsyMac The index of the first-past-the-end element of some array of 'sy'. Whilst inarguably a really stupid name -- it would be useful to
know which array it was -- it certainly doesn't code for the compiler type of the variable.
PsySz A function accepting a zero-terminated string and a returning a pointer to a sy. Obviously a terrible function name. Clearly codes for the compiler type of the return value. However, "char[]" isn't
necessarily zero-terminated, so that codes for a well-defined subset of character arrays which cannot be expressed as a compiler type.
pch Pointer to a character. Codes for the fact that it's a pointer, and that it points to a character. Wrong on both counts.
cch Count of characters. Nothing to to with its compiler type.
psy Pointer to SY. Wrong on both counts.
PsyCreate Codes for return type.
pbsy Pointer to a index into an array of SY. Codes for it being a pointer, but 'b' and 'sy' do not code for its compiler type.
cwSz A count of words in a zero-terminated string. Doesn't code for its compiler type.
wHash A word which stores a hash value? Or a hash of a word?
cwHash A count of the number of words in a hash table.
rgbsyHash An array of indices into an array of SYs, used as a hash table. 'rb' might code for compiler type unless it's declared as a pointer.
szSy A zero-terminated string which in some fashion represents an SY. As above, "char*" alone is not enough to establish that a zero-terminated array is being pointed at.
By my counting:
8 prefixes which redundantly code for the exact compiler type of the object they name.
17 prefixes which code for the type of some other object, a functionally distinct subset of the compiler type, or just usage.
3 prefixes which might go either way.
Quote:
It is pretty clear from the above example that Simonyi meant 'type' in the regular usage of the word when he wrote 'type', and that others coming along behind him argued that he meant 'usage' without really reading the article.
It is pretty clear from the article that people who read the article would know that he
didn't mean 'type' in the regular usage of the word when he wrote type.
There is, however, something I think we can both agree on. The follow snippet from the article is purest nonsense:
Quote:
In closing, it is evident that the conventions participated in making the code more correct, easier to write, and easier to read.
