Talk:Hungarian notation

To be corrected

The link "Charles Simonyi's explanation of Hungarian Notation" is no longer accessible. I don't delete it because perhaps someone knows the correct name. ChewbaccaKL (talk) 14:43, 5 May 2008 (UTC)

I looked into it with the Wayback Machine. It appears to have been [this page], already cited as reference 1, so I removed it entirely. EvanED (talk) 18:57, 5 May 2008 (UTC)

Brain damaged

First, as per Linus Torvalds, compiler will check the types anyway. Second (noted under 'Blight' below as well), if you can't keep track of your variables in the scope, no mnemonics will save you (and if your excuse is 'large project' - well, your employer should start looking for other contractors). Third, read the article by Andy Hertzfeld (http://folklore.org/StoryView.py?project=Macintosh&story=Hungarian.txt) aptly named 'Hungarian'. To paraphrase (if you're too lazy to read the article): since early compilers had very restricting limits on variable names, Simonyi's solution was to preserve the type prefix BUT leave out the vowels (!). On the forth hand (in case you're counting :) Microsoft itself abandoned Hungarian notation in all of their publicly released guidelines (can't vouch for internal use, though).

Torvalds' comment pertains to Systems Hungarian and is absolutely a germane criticism. Compilers in common usage, however, are not able to check for correct usage in code of an abstract data type, so compiler technology does not obviate the need for Apps Hungarian.

Mnemonics may not save you but well-crafted Apps Hungarian tags will tell you many things that must be true in a software routine that are not expressed by the routine's data declarations, thereby increasing your coding efficiency.

Herzfeld's crack is bogus. Simonyi wanted to restict the size of Hungarian coinages to two, three or four characters because he realized that there was great power in being able to compose Hungarian prefixes to describe arbitrarily complex data structures. Allowing tags to be larger reduced the probability that someone reading the code would be able to easily parse a name and hold it in mind. He dropped vowels in his coinages to achieve the concision he desired.

Systems Hungarian was banned from the Windows NT project by its chief architect Dave Cutler. His decision to do this was correct, in my opinion.

Apps Hungarian is used throughout the subprojects of Microsoft Office that were developed at Microsoft campus in Redmond, Washington (Word, Excel, Access, and Outlook). Usage of Apps Hungarian there hastened the ease with which the Office team was able to abstract common services to be shared between these products.

Many who have worked on those teams consider usage of Apps Hungarian to have been a major competitive advantage in the effort to win market share from the Lotus 1-2-3 spreadsheet and Word Perfect word processor. The development teams used by Microsoft were usually reputed to be an order of magnitude smaller in size than those that were used by Word Perfect or Lotus (10s of developers rather than 100s). Some believe that Hungarian usage accounted for a sizeable proportion of this disparity in team size.

DLuebbert 07:58, 13 October 2007 (UTC)

We certainly used it in our project at Microsoft (the Virtual Worlds Group). Redundancy is part of how systems engineering attempts to reduce errors and increase code readablility and maintainability and naming consistancy. The point is not whether the compiler can deduce the type, the point is that a human can look at a small portion of code and know the types. DonPMitchell (talk) 18:53, 12 September 2012 (UTC)

Blight

Hungarian Notation is a blight on the world!! 24.160.136.10 01:27, 12 March 2006 (UTC)

I second that. If you are writing functions/methods that are so huge that you forget the types of what you are accessing then you have a problem. If your name space is so poluted that you can't remember the types of what is stored there then you have a problem. If you think that hungarian notation is a good idea then you probably have a problem. --207.81.225.190 01:41, 5 July 2006 (UTC)

---

This idea is much older - Fortran has such rules, by example, all integer variables names begin with an "I" .

If I remember my Fortran Coloring Book it's actually [I-N]* (using shell patterns) - I and N being the first two letters of "integer".

Not all agree with the philosophy of putting the type of a variable in its name; what if the type changes? (The W³C makes this objection re URIs. There's a story "out there" that Billy G rejects it with "so? do a big search-n-replace" which to some says he's got little grip ... eg what if you're read-only on some of the affected code? what if your search string happens to clobber something it shouldn't?) 142.177.23.200 14:43, 19 May 2004 (UTC)

it really drives me crazy that this issue goes around and around, and understanding is never achieved: you are absolutely correct, don't name a variable after a type that might change. However, this puts you in the pro-hungarian camp, not the anti-hungarian camp. You are supposed to use the abstract type, i.e. come up with a hungarian name for "bank balance" and use it for your bank balance variable. this "type" has all of the attributes of a bank balance. it does not matter whether your bank balance variable is implemented as an int or a real or a struct or a class etc., the abstract type remains the same.

Your whole argument starts at selecting the wrong types for your variables - types which are to general. You should have a type "BankBalance" (which could, for example, also have an attribute for the currency - that would prevent you from accidentally transfering 100 times what you wanted because you thought the int meant Cents, when it meant Dollars). AlgorithMan (talk) 14:50, 21 March 2018 (UTC)

---

Sorry but what does "hungarian notation" has to do with RPN? O_o

It is called Hungarian notation because Simonyi was of Hungarian extraction. In a similar way Reverse Polish Notation was called Polish because its inventor, Lukasewicz, was of Polish extraction. Davidlu 07:46, 17 Nov 2004 (UTC)

---

The best counterexample for the usefulness of Hungarian notation is IMHO provided by Microsoft themselves. From How To Write Unmaintainable Code:

One followon trick in the Hungarian notation is "change the type of a variable but leave the variable name unchanged". This is almost invariably done in windows apps with the migration from Win16 WndProc(HWND hW, WORD wMsg, WORD wParam, LONG lParam) to Win32 WndProc(HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam) where the w values hint that they are words, but they really refer to longs. The real value of this approach comes clear with the Win64 migration, when the parameters will be 64 bits wide, but the old "w" and "l" prefixes will remain forever.

I'd like to see a brief mention of this in the article itself. I haven't added it myself because I also want to avoid an edit war. --Yamla

---

The Wikipedia article does not accurately describe the features of Hungarian Notation or its utility in the development of large software projects.

Hungarian Notation has greatest utility in large software projects that might define 1000 or more different data types and might have 100,000 or more procedure or class method definitions defined. Simonyi introduced the notation in an attempt to describe how a Software Factory might work.

The Microsoft Applications Group, where Simonyi was lead developer for a number of years, utilized the form of Hungarian Notation described below in the development of Microsoft Word, Multiplan, Chart, File, Excel, and Access. That development organization, the predecessor of today's Information Worker Business Unit which is responsible for the development of the Microsoft Office products, could be viewed as a kind of software factory similar to that imagined in his thesis.

When Hungarian is used in such a project, a unique small 2-4 character unique alphanumeric tag is generated for every data type defined in the project. That tag name, spelled in all capitals, is used to name a type in its type definition. Any data instances of that type used in the project, are named using that tag name spelled in lower case.

There are primitive data types defined in Hungarian, that correspond to the primitive types provided by a particular programming language. The primitive tags commonly used in Hungarian are frequently one or two character abbreviations of the type names used in the C language.

The Wikipedia article seems to report that Hungarian Notation recommends the usage of primitive tags throughout a project. This is untrue.

The primitive tags ARE predominantly employed in code that performs generic processing on data where more detailed type information is obscured (heap managers, string handling routines, etc). However, when primitive types are used in more restrictive contexts (short integers used to encode screen pixel coordinates, color palette indexes, indexes to arrays of a particular type, file identification numbers, document identification numbers) more restrictive Hungarian tags are coined that describe the meaning and usage of that more restrictive type(eg. xp and yp for horizontal and vertical pixel coordinates, co for a color palette index, ifoo for the index to an array of type FOO, FN for a file ID, DOC for a document id).

If it is necessary to reimplement a restrictive type using a different primitive type implementation (eg. change type declaration from short to long in C) this is done with no great clamor or consequence.

When a record or class type is defined in the project, a unique Hungarian tag is coined for it. In a large project, usage of these record/class tags nearly always predominates over that of the primitive tags and their restrictions.

When Hungarian is used in a multi-programmer development project, the Hungarian tags become the nouns that the programmers use when they describe their algorithms in specifications or in conversation with other project members. The tags names are pronounced as words when they are pronounceable and otherwise are spelled out.

The published HN article, talks about lower-case mnemonics being used to express the type or purpose of an instance variable, without mentioning the role that composable prefixes play in the notation. Prefixes are used to label different compositions of data types and to generate a small number of standard derived types from an existing type.

Most modern programming languages provide pointer and array constructs that allow programmers to traverse links from one data structure to another and to pick out a particular data item aggregated into an array. Hungarian notation predefines prefix types that can be added to Hungarian type tags to describe the meanings of pointers and arrays defined within a project.

Common composable prefixes:

p - pointer to data of a particular type. A pfoo instance would be a pointer to data of type FOO. 
pp - pointer to a pointer that points to data of a particular type. A ppfoo instance would be a pointer, which points to a pointer that points to data of type FOO.
h - a pp pointer that resides in a memory managed heap.
rg - an unstructured array called a range in Hungarian. A rgfoo instance would be an array which stores instances of type foo. An rgfoo would be indexed via an instance named ifoo (an index to foo)
mp - a specialized array which maps instances of one type into instances of another type. For instance, if the DOC hungarian type were a small integer doc number, a mpdochdod type indexed by a particular doc would produce a hdod, a handle to a document descriptor that corresponds to that doc number. 

These prefixes can be composed and prefixed to a Hungarian type tag to name data instances that are the starting points of complex data structure traversals.

Example:

 A rghrgpfoo would be a range (rg) of handles (h) which each contain a range (rg)
 of pointers (p) to data items of type FOO.

Common prefixes for derived types:

i - ifoo would be an index in an array rgfoo that contains elements of type FOO
c - cfoo would be a count of elements of type FOO
d - dfoo would be the difference between two elements of type FOO
b - bfoo would be the relative offset to a type X. This is used for field displacements
    in a  data structure with variable size fields.
cb - cbFOO would be the size of an item of type FOO measured in bytes
cw - cwFOO  would be the size of an item of type FOO measured in words

The article does point out the usage of a modifying suffix to produce an unambiguous given name for instance variables. No mention is made of the practice of using standard modifying suffixes to express invariants which restrict the usage of an instance or the usage of a developer coined hint which describes how the instance may be used in a routine.

Some of the standard suffixes which express invariants are:

Max - added to an index data instance which records the actual size of an array or data block. 
     eg. the declaration of a an array of type FOO in C would be: FOO rgfoo[ifooMax];

Mac - added to an index data instance to indicate the limit of a actual usage 
    within an array. Mac stands for current naximum. It is invariant that 
    ifooMac <= ifooMax. ifooMac == ifooMax is the condition which is true 
    when all entries within an array are in use. 

First - added to an index or pointer which designates the first element 
        within a range that may be validly processed

Last - added to an index or pointer which designates that last entry 
    within a range that may be validly processed.

Lim  - stands for limit. An ifooLim is equal to ifooLast + 1 and 
        designates the location where a new foo item  could be recorded in an 
        array or data block.

There is a Hungarian standard for naming functions and procedures that is unmentioned in the article. In many cases these names quote the data tags used as parameters and the type of the return value if one is generated.

The example data item names displayed are all malformed except for the examples of zero-terminated strings and pointer to zero-terminated strings

A more complete description of Hungarian Notation can be found at [Description Of Hungarian And Its Benefits]

The author of the article is a software developer who worked under Simonyi's direction on the Macintosh Word project for 5 years (1984-1989) and who has employed Hungarian Notation in his development work for 20 years.

Davidlu 06:48, 17 Nov 2004 (UTC)

I can vouch for the accuracy of Davidlu's description. I think it should be moved into the main article page (minus the criticisms of the current page, of course). Aside: my favorite variable on the BravoX project (at Xerox, in BCPL) mapped windows (ww) to window descriptors (wwd). Its name was, of course, mpwwwwd. Rlw 19:32, Feb 14, 2005 (UTC)

On the other side of the coin: not everybody uses Hungarian Notation that way. When it's misused, as it very often is, it doesn't suddenly become something other than Hungarian Notation. Moreover, there's a large tendency to misuse it. Some people argue, therefore, whatever Hungarian Notation's merits, it shouldn't be used because it will be misused far more often than used correctly, so encouraging its use does more harm than good. Neither of these opposing points of view are really reflected in the article, and I think they should be (it doesn't violate NPOV if it presents a balanced argument). - Furrykef 01:13, 19 Nov 2004 (UTC)

It would perhaps be valuable to make clear that there were two forms of Hungarian Notation that have been widely employed. The first, documented in my comments above, was Apps Hungarian utilized by the Microsoft Applications developers who worked under Charles Simonyi’s direction.

That form became a backbone development practice of a number of successful large application development projects at Microsoft and had been used earlier by the developers who wrote the Bravo word processor for the Xerox Alto at Xerox PARC also under Sinonyi’s direction.

This first form was documented as part of Simonyi’s Ph.D thesis at Stanford and was little read by the public. The relevant parts of the thesis were excerpted and published as internal technical documentation within Microsoft, and were taught to new Applications Group programmers orally and via code reviews.

Microsoft took no pains to ensure that the Apps Hungarian form was properly documented and promulgated to the public. It’s proper usage was considered to be part of the company’s development lore and that there was no obligation to ensure that outside parties knew how to properly apply the technique.

The System’s variant of Hungarian, which is the variant that is best known outside of Microsoft, had a weird, uncalculated, accidental genesis within the Microsoft System’s group. Scott Ludwig, one of the young developers on the Windows 1.0 team, took it upon himself to try to get Hungarian adopted within that team. He knew the Apps form and used it in code that he wrote and evangelized others to use it.

Every thing went well until Microsoft’s documentation folks got hold of the team’s work and decided they didn’t want the public to see it.

Quote of Scott Ludwig from the comments for [Larry Osterman's blog at Microsoft] :

“The story is that the hungarian bastardization originally came from the documentation folks. In the systems group we originally produced raw documentation for them that had standard "apps like" hungarian. They decided it was too obtuse for documentation so they did some serious readability changes to it. They are not programmers so this wasn't a graceful operation. This had a *huge* secondary effect because new programmers in the systems group would read the documentation and "more or less" reproduce that "documentation group" style. Not to mention books were written about the API that referenced that style. Pretty soon we had more code in this "docs group" style than in any other style.”

The major books that referenced the bastardized “Systems” Hungarian were Petzold’s “Inside Windows” volumes. These volumes documented the notation used in Microsoft Windows documentation, a reasonable thing to have done, but unfortunately represented the form described as the notation invented by Simonyi.

Folks outside of Microsoft heard of Microsoft Applications’s success using Apps Hungarian and had no reason to believe that Petzold was describing a different beast entirely. It was adopted in the outside world on the strength of the Apps Hungarian reputation. Experience with Systems Hungarian showed to many that this Petzold promulgated variant was a major Anti-Pattern.

When David Cutler, the architect of Windows NT, came to Microsoft from DEC, it is said that he banned the usage of Systems Hungarian from the NT code tree.

From the comment above:

"On the other side of the coin: not everybody uses Hungarian Notation that way. When it's misused, as it very often is, it doesn't suddenly become something other than Hungarian Notation. Moreover, there's a large tendency to misuse it."

Actually, most people outside of Microsoft use the accidental and discredited System's Hungarian. (At least one Microsoft employee has taken to calling it Anti-Hungarian, since its tenets are in opposition to what Simonyi proposed when he invented the notational scheme). It is misuse to use it and those who do use it should stop doing that as soon as they are able.

The Hungarian Notation that Simonyi invented, Apps Hungarian, has shown high utility in a number of large software projects. Those of us who have experienced its utility would like to see that it is properly represented in public forums like the Wikipedia

How's that for NPOV? ;-)

[Another article that discusses the Apps and Systems Hungarian conundrum; coins the term Anti-Hungarian to describe the Systems Hungarian variant] Davidlu

How about scoping?

As I learned it, Hungarian notation includes a separate set of prefixes for showing the scope of a variable. These scoping prefixes are followed by an underbar. Here are a few of them:

m_ Member of a class ms_ Static member of a class s_ Static, not in class g_ Global

Perhaps we could add this.

On another note, good job on distinguishing between Apps and Sys. I'd suggest going further by explaining that Apps is Abstract while Sys is Concrete, and hinting that the former is more powerful. Sound good?

C or BCPL?

The article states that the notation was designed with the language C in mind. I believe this is not the case. The notation was actually used with the language BCPL, which predates C. BCPL has no types other than the machine word. I know this because I worked for Simonyi at Xerox programing in BCPL.

Rlw 18:32, Feb 13, 2005 (UTC)

I came across this page and noted that the introduction contradicted the rest of the article, which said that HN was created for Microsoft Windows. I tried to correct this, and also found Simonyi's PhD thesis on the net, where he discusses this notation, among other things. As far as I can tell it's pretty language neutral, although he mentions BCPL and Algol W. DBrane 13:35, 14 Feb 2005 (UTC)

Origin, Systems vs. Apps

I'm not sure how true this is, and it's at least not nearly as strong a division as some articles (I'm thinking specifically as "Making Wrong Code Look Wrong") imply. The sixth link down doesn't seem to discuss the original intent, though I only glanced at it and searched for misunderstanding, systems or Simonyi.

If you actually look at Simoniy's paper, there are a number of suggestions that he gives for prefixes. Some, like cb and d (the count of something and a difference, respectively) are semantic information, and this seems to be what this article and "Making Wrong Code Look Wrong" call Apps Hungarian. But he also recommends stuff like w and p that contain NO semantic information, and this seems to me to be strictly in the Systems Hungarian camp. (Some, like sz, span both categories.) So I don't think that the main article is currently accurate in stating that "the word "type" was misunderstood to mean 'data type'". In other words, while what he recommended was broader than Systems Hungarian, it wasn't disjoint from it either.

At the VERY least, the statement that Systems Hungarian is a misinterpretation of Symonyi's proposal is blatently and falsely inconsistent with the statement that the sz prefix is Systems Hungarian.

I'm going to attempt to edit the main article soon to fix this to the best of my ability, but I'm concerned slightly about maintaining NPOV. If someone feels I have violated it, please feel free to edit, but keep the above in mind and specifically keep in mind that simply reverting to what is currently present is picking between the evils of an unintentional and hopefully small NPOV violation and getting part of the article flat-out wrong.

-- EvanED

Simonyi did introduce generic type tags (b,w,l,ch) which correspond to the primitive types provided by many data structures. He did introduce the p prefix but that would always have been bound to a particular base type (pb -pointer to bytes, pw - pointer to word, pl pointer to long, pch-pointer to character).

The intention was that generic type tags would only be used when a programming procedure was operating upon generic data whose meaning was obscured, such as happens in a memory management routine that operates on abstract blocks of data of byte, word, or long length, or in string handling routines that deal solely with arrays of characters. If it was possible to know that a perticular data item refered to a document number, a color, and x-pixel position, or a distance between two pixels more specific Hungarian tags like doc, co, xp or dxp would be coined and used in preference to the generic types.

Systems Hungarian practioners don't make use of the Apps Hungarian idea that every distinct record or object declaration defined in a software project deserves its own unique Hungarian tag. The list of Hungarian tags used in a development project constitute a glossary of all of the abstract data types defined there.

The error of Systems Hungarian usage was to deny that these more specific tags describing abstract data types existed and were highly useful to those engaged in software developement. The Microsoft documentation folks who bastardized the notation had no conception of the damage they were commiting. They did it because the assembly programmers who were major clients of their Windows API guide were highly interested in the size of the paramters that were being passed them. Using the generic tags made sense to the writers and their clients, but doing only that excised most of the information carrying capacity of the notation.

I do admit that the sz prefix is used in both Systems and Apps Hungarian, but Systems Hungarian IS a gross misinterpretation of Simonyi's proposal.

DLuebbert 07:24, 13 October 2007 (UTC)

---

cb stood for "count of bytes", just as cch meant "count of characters", cdod could mean count of Document Descriptors, and cfoo would mean a count of foos. When a generic routine was being written in which the data abtraction being used was a range of bytes (rgb) it would be appropriate to name a count of bytes as a cb. When it was appropriate to use higher level abstraction, such as an array of records, (eg. struct CHP rgchp[]), a user of Hungarian would refer to counts of instances of that structure (eg. cchp).

A d prefix used by itself would be an ill-formed Hungarian construct. The prefix was used to describe a variable which stored a distance measurement, a subtraction between coordinates. One would always attach a tag after the prefix to describe what kinds of coordinates were used to calculate the difference. When a type was used to describe a coordinate (eg. xp which described x pixel positions in a bitmap, or yp which described y pixel positions in a bitmap), a dxp (a difference measured in x pixels) would necessarily be calculated as dxp = xpLarge - xpSmall.

w was used to refer to a word of memory (16-bits, 32-bits, 64-bits), which depended on the computer's word size. Again this would be used only in very generic situations (eg, a memory manager) where higher level abtractions couldn't be used.

A p was the prefix to describe a pointer reference. It would be ill-formed to speak of a p without attaching a tag which described what the pointer was pointing to. A pointer to bytes would be a pb, a pointer to a character would be a pch, a pointer to a DOD wpould be a pdod, a pointer to a structure named FOO would be a pfoo.

Systems Hungarian gave the impression that generic data tags were to be used preferentially when writing code. Apps Hungarian practitioners would instead coin unique tags to describe all of the data abtractions that were in use within a software project and would eschew the usage of generic tags whenever it was possible to use tags that described the higher level constructs that were in use in a routine instead. davidlu DLuebbert 19:18, 29 January 2007 (UTC)

At the top: "This document refers to Systems Hungarian notation. See external links for Apps Hungarian notation." deve Under Origin: "Hungarian notation was invented by Charles Simonyi"

This combination of statements is potentially misleading. It could be interpreted as stating that Simonyi invented Systems Hungarian notation. In fact, Simonyi only invented Apps Hungarian. Systems Hungarian grew out of a misunderstanding of Simonyi's invention. As explained by the sixth external link down. -- Smjg 15:04, 25 August 2005 (UTC)

What pray tell does "Apps" mean? In a contentious field such as naming conventions I dare not assume it means the plural of "application" DEddy 16:42, 15 July 2006 (UTC)

In the late 1980's, the division of Microsoft that created applications programs such as Multiplan, Word and Excel was called the Applications Group. In daily conversation this was frequently abbeviated as the Apps Group. Simonyi was the lead developer and Chief Architect for this division. The Operating Systems Group was the division of the comapny that was responsible for the companies operating Systems, MS-DOS, Windows, Xenix, etc. That group's name was frequently abbreviated as the Systems Group.

Apps Hungarian refers to the form of Hungarian used to write the applications in the Microsoft Applications Division. That version was felt to very effective and useful when used to construct large applications. Systems Hungarian was the form that was promulgated by the Microsoft Operating Systems Group. The usage of the Systems Hungarian variant was eventually quashed by management of the Operating Systems Group. David Cutler, the architect of Windows NT, reportedly banned the usage of Systems Hungarian in that development project. davidlu DLuebbert 19:18, 29 January 2007 (UTC)

To say that the disadvantages section only applies to Hungarian notation is not true. Apps notation is ugly, unpronouceable, and has many of the same problems as Hungarian notation. I'm guessing here but I think the only reason Apps notation exists is because of some internal political struggle within Microsoft. Firefight (talk) 15:24, 7 June 2012 (UTC)

Apps Hungarian predates the systems variant by a number of years, and was introduced to the Microsoft Systems Division by migrant junior developers who previously worked in the Applications Division.

Consult Scott Ludwig's testimony in the "Blight" section above which reports how Microsoft's Documentation Group altered the presentation of Hungarian in Systems documentation to make it "easier to understand", thereby misrepresenting what concerns motivated the usage of Hungarian and actually promulgating an incorrect and bogus version of the notation. Unfortunately, Petzold amplified these misconceptions of Hungarian in his "Inside Windows" volumes. Over time Petzold's work became an authoritative reference to Hungarian in the world outside of Microsoft.

In chronological order, the Apps idiom was used to develop the entire corpus of source code for Microsoft Multiplan, Word, Chart, File, Excel, Works, Access and most of the shared code written for the Microsoft Office suite, which was abstracted from the separate implementation of similar functions, mostly user interface, file system, spell check and grammar check functionality.

Those redundant application parts shipped separately as parts of the original releases of the constituent Office applications. These were later re-implemented as libraries that were shared by the Office apps, after it became clear that Office as a suite of applications marketed as a unit was going to be a marketplace success.

Apps Hungarian notation was also used in the development of all of the compilers, p-code interpreters and software tools that Apps Division wrote for itself to produce the shipping and test versions of their applications.

By the time the systems variant became known to the outside world, the original apps variant had been used to notate close to a million lines of the source code of the application programs that the Microsoft Applications division had shipped up to that point.

After the bifurcation of the systems hungarian idiom from the Apps Hungarian occurred, tens of millions more lines of source code were written using the original Apps idiom.

Apps Hungarian was embedded in the entire fabric of those listed applications. It was not possible to even conceive of "converting" code written in the Apps variant into the Systems variant. That would have required Herculean work that would have produced no user or development benefit, and indeed would have been a self-defeating course of action to undertake that would have led to nearly instant failure of future development efforts by the Applications Division.

It would have also been a disaster for Applications Division to do this conversion because that would have required that incredible amounts of application development knowledge be purged from projects, which was already concisely and compactly recorded in the Apps source code during app development, since the Apps Hungarian notation idiom was used to name the data objects and procedures of that code.

We would have then had to re-express and re-record all of that information close to the re-expressed code in a much less compact and less comprehensible form to have a hope of dealing with the code in the future.

Apps Hungarian was the lingua franca that allowed us to discuss and easily master the mass of code that we maintained for our applications development. Forbidding its use would have led to the confounding disasters similar to those that the Bible report befell mankind after the Lord scrambled human speech to punish the hubris of the erection of the Tower of Babel.

I would grant that it is correct to say that Hungarian names were not 'obviously pronounceable'. Despite that, Apps Hungarian practitioners found that it was pretty easy to pronounce Hungarian names if a few rules were followed.

Microsoft Applications developers would have failed monumentally as software developers if there was not an efficient way to communicate via Hungarian.

As it was, Microsoft Apps Division could compete successfully with staffs of 10 to 15 developers against its competitors, who were already using staffs of hundreds to produce their products (Word Prefect, Lotus and Ashton-Tate). Many within Microsoft thought that the Hungarian notation used in application development allowed Microsoft software engineers to work and collaborate with that kind of 10 times or better competitive efficiency.

When prefixes of composition were used in a Hungarian name (eg. rg, mp, dn, pl, plc, p, h) we would expand the prefix and name the kind of structure that we were dealing with. An rg was a range (an unstructured array of records), an mp was a map (an array that transformed a meaningful array index into a different datatype), a dn was a domain (an array that stored information corresponding to a particular meaningful type of array coordinate), a pl was a plex (a generalized variable length array), a plc was a plex of character positions (a generalized variable length array whose entries were in one-to-one correspondence with a sorted, searchable array of character positions that marked significant locations within the text stream of a document), a p was a pointer, an h was a handle.

If a hungarian tag contained a vowel, we pronounced that tag using the rules of English pronunciation. A SED (a SEction Descriptor) was pronounced like 'said', a PAP (a PAragraph Property block) was pronounced 'pap', like Huckleberry Finn's father's preferred nickname.

If a tag did not contain a vowel and was frequently used, if we could, we pronounced it with a vowel sound that fit comfortably within that consonant cluster. A CHP (a CHaracter Property block) we pronounced as a 'chip'. A STSH (a STyle SHeet record) we pronounced as a 'stish'.

If a tag was consonantal and two or three characters long, and a vowel didn't automatically suggest itself to make it easier to pronounce, we spelled it out letter by letter.

A CP (Character Position in a Word document) we spelled out as a cee-pee. An FC (a File Character position) we spelled out as an eff-cee.

If we saw mpdochdod[ ], we pronounced that as map-doc-to-aitch-dod, if the person we were speaking to was an old hand with Word code. If we were speaking to a new programmer who was still learning the lingo, we would say that this array was a map from a DOCument number to a handle that references a heap data block that records a DOcument Descriptor.

If we saw hplcbteChp or hplcbtePap, we pronounced that as an aitch-pleece-B-T-E-chip or an aitch-pleece-B-T-E-pap. When we were speaking to neophytes, for their benefit we would read that as a 'handle to a plex of character positions in 1-to-1 correspondence with an array of Bin Table Entries that we search to locate the corresponding CHaracter Prop or PAragraph Prop for a particular Character Position'. Notice how two 11 character object names mentally expand into an accurate 34 word description of what these objects really are. Notice also how a six syllable name expands into this long but accurate explanation when a programmer understands how to parse an Apps Hungarian name using the object's shorthand pronunciation.

If we saw sprm (a Single PRoperty Modifier), we pronounced that as a 'sperm', a numerical opcode that had an operation payload following that specified which single property value in a property block should be changed and described how it should be changed.

If we needed to find out the length of a sprmCFBold operator, which sets the bold flag in the CHP (character prop block), we would reference the dnsprm[sprmCFBold].cch, which we would pronounce as the cee-cee-aitch (count of characters) value of the sprmCFBoldth entry of the domain of sperms.

If we saw a dndl[ ], we would pronounce that as a dee-en-dee-ell, and call it a domain of Display Lines. If we wanted to know the upper left corner coordinates of the 5th line displayed in some window area, we might reference the pwwd->dndl[5].xpLeft and pwwd->dndl[5].ypTop, which we would pronounce as a 'pee-double u-double u-dee right lump fifth dee-en-dee-el entry's ex-pee-left and why-pee-top'.

For a neophyte we'd expand that into "a Pointer to Window Descriptor that points to the domain of display lines for that window (an array that stores info about each line displayed in that window) where we would like to access the 5th entry in that domain corresponding to the 5th line displayed in that window, in order to lookup the xpLeft horizontal pixel coordinate and ypTop vertical pixel coordinate values stored within that entry, where xp and yp values are measured from the upper left corner of the window".

If we saw rgstu[istu] we'd say that we were indexing a range of stu with an eye-stew. For neophytes we might say that we are indexing an unstructured array of STUdent records using an integer index to student.

We would likely expect that this reference occurs within the bounds of a loop construct that initializes istu to 0, which iterates until istu is equal to istuLim (the limit coordinate of the array of STU, pronounced eye-stew-lim).

I hope that I've demonstrated that apparently unpronounceable Hungarian data object names and procedure names were pronounceable by programmers who had absorbed a particular project's development culture and that Hungarian names were pronounced in a short hand or expanded form who's use depended on the experience level of the programmers who were participating in a discussion about application source code.

Those who were versed in the art could pronounce a project's Hungarian names pretty easily a week or two after exposure to the Hungarian usages of a new software project. After that small amount of overhead was paid, Apps Hungarian practitioners frequently testified that they could write code faster while introducing fewer faults into their projects, that verbal and written communications about code became much quicker, much more precise, and less confusing, and that code became much easier to comprehend, especially when a reader was not the code's original author.

I would guess that the Cyrillic, Greek, and Gothic scripts all look dismayingly ugly to those who are used to Roman orthography. The lack of vowels in the Arabic and Hebrew alphabets I'm sure dismay many who fluently read text that is rendered using the common European alphabets. I'd imagine that all programming notations likely look unbearably barbaric and drearily ugly to those who's only language experience is with their mother tongue. Such notations can acquire an aura of beauty when a person experiences how ideas that are nearly impossible to express accurately and fluently in unrestricted language become easier to think about when a felicitous notation is adopted. Apps Hungarian practitioners tended to experience Hungarian with that kind of aura after they used it for awhile as they attempted to solve hard programing problems as part of a programming team that was working at high efficiency.

I'd like to know what other problems you believe that the Apps Hungarian notation shares with Systems Hungarian. I am convinced that many/most of the valuable features of the Apps idiom were stripped away and discarded when the Systems idiom was promulgated outside of Microsoft.

DLuebbert (talk) 01:16, 2 January 2013 (UTC)DLuebbert

Ruby instance/class vars and conventions also count as sigils?

I doubt this should be added to the article, but I was curious if the Ruby instance and class variables requiring @ and @@ prefixes counted as sigils possibly along with the conventional postfixes on boolean returning methods and destructive methods (? and ! respectively, as in some_object.valid? or other_object.substitute!(original, change) )

Thanks

Array example

The current article says: "rgStudents : array, or range " Isn't this a bad example?

Shouldn't rg be combined with a prefix describing the datatype? Suggestions:

rgstStudents: Array of Student structures

or

rgszStudentName: Array of zero-terminated strings with Student Names

—The preceding unsigned comment was added by 134.47.109.184 (talk) 09:48, 11 January 2007 (UTC).
AndrewR

This example is bogus Apps Hungarian. An st is a Pascal-type character string.

If there were a student record, it would most likely be given a three character Hungarian tag, such as STU. An array of student records would be called an rgstu[] ( a range of STUs).

The STU structure might contain any number of subfields (first name, last name, initial, street address, city, state, zipcode, current classes enrolled, current gpa) each of which would be given an appropriate Hungarian name.

If it became necessary to add new fields to the structure (eg. date of enrollment), that field would be entered into the structure definition and would be given a unique Hungarian name within the structure.

This is how such an STU might be declared in C using Pascal strings (st) to encode the string typed data:

1. define CLC short // type declaration for a class code, an integer index into the institution's master course catalog
2. define GPA float // type declaration for a student grade point average (gpa)

struct STU {

   char stNameFirst[40];
   char stNameLast[60];
   char stInitial[1];
   char stStreetAddress[100];
   char stCity[25];
   char stState[20];
   GPA  gpaCur;
   CLC rgclc[10];  // clc is the tag for a class code. It is an index into the school's master class catalog
   };

DLuebbert 18:20, 13 October 2007 (UTC)

Nearly all Examples in article are bogus examples of Apps Hungarian

I can't speak to whether they are all well-formed in any Systems Hungarian variant.

---

A bBusy tag is not a well-formed boolean flag name.

The b prefix is used to name a data item which is a byte value or a byte offset within a data structure. A boolean flag which encode a busy state should be declared as

Boolean fBusy; // a flag encoding a Busy state

---

cApples is not a well formed Apps Hungarian construct. The c is a count prefix. Apples is a suffix that is meant to identify some specific instance of a type. It is essential that there be a type classification in this name.

If there were an FRT, a fruit description type defined, then it might make sense for there to be declarations

FRT rgfrt[]; // fruit collection recorded in array

short cfrtApples; // count of apples recorded in fruit collection

short cfrtOranges; // count of oranges recorded in fruit collection

short cfrtPlums; // count of plums recorded in fruit collection

---

dwLightYears is not well-formed. a d prefix indicates that the items is the difference between two items of the base type (w). A difference of two generic words, is a queasy making, unuseful construct.

The generic tag l (for long) has the meaning of double word. If you carelessly used generic tags, you might properly declare this to be a lLightYear.

Much better, a Hungarian tag, would be coined to describe a year structure, called it a YR. Then the appropriate instance declaration might be

define YR long YR yrLightYear;

If light years needed to be a separate type from a normal year because of the operations that it is allowed to participate in, it might be better to coin an LYR type. like this:

define LYR long LYR lyr;

---

The n in nSize has no agreed upon meaning in Apps Hungarian although I have ssen it used to describe a generic integer value. Most folks who knew Apps Hungarian, who saw this would cringe and expunge it.

If you had a structure tagged FOO, cbFoo would be the count of bytes in the FOO structure, and cwFoo would be the count of words in the FOO structure

---

I believe an iSize would be considered well-formed Systems Hungarian. It is meant to label an integer value that is used as a some kind of size.

It is a bogus construct in Apps Hungarian.

In Apps Hungarian, you might create an SZE tag to label a size variable. It might be declared thus:

define SZE short or define SZE long;

If there were a collection of type SZE sizes that was recorded in an array declared

SZE rgsze[];

short isze;

would be the proper declaration for a an index which accesses a particular element in an rgsze[] array.

---

I have not seen fp used as a tag for floating point value. I have seen it coined as a tag to describe a file position.

fl is usually the tag used to describe a generic floating point value.

flPrice would be a better Apps Hungarian naming.

If prices were specialized floating point values in any way, we would most likely define a specialized type for prices, like this

1. define PRC float;

PRC prc;

---

dbPi is acknowledged to be a Systems form. I think in Apps we would just name the constant as pi, and consider it to be a type in itself

float pi 3.141526;

---

pFoo is a Systems construct but is an ill-formed Apps Hungarian name because it consists of a prefix and a suffix modifier with no type tag between. The correct declaration in Apps Hungarian would be

FOO *pfoo;

The foo must be lower case because it is providing the type of the pointer

In a procedure you would very frequently have pointers that would have suffix modifiers added to the end to document their function, such as

FOO *pfooFirst, *pfooLim;

In Systems Hungarian, a p is considered to be a primitive type, a pointer. In Apps Hungarian, a pointer can never make sense unless one knows the type of data at which it is supposed to point.

---

rgStudents (see comment in the topic above discussing use of a STU type)

---

szLastName is a valid name using the sz primitive type in both the Apps and Systems notations

---

stTime would be interpreted as a pascal-type character string which contains a displayable time value in Apps notation.

In Apps notation, if you had a time data structure, you would coin a new type, which you could call TM, TME or TIME at your pleasure. The correct declarations, given these coices would be:

struct TM

 {
 } TM;

TM tm;

or

struct TME

 {
 } TME;

TME tme;

or

struct TIME

 {
 } TIME;

TIME this

TM tm;

DLuebbert 18:36, 13 October 2007 (UTC)

all the objections are just 4 systems Example99 (talk) 17:28, 21 February 2023 (UTC)

Clarification of the use of "type" needed

I think the article needs to be rewritten with the following taken into account.

http://blogs.msdn.com/ericlippert/archive/2003/09/12/52989.aspx.

Note how the use of "type" has been incorrectly interpreted by the masses into the version of Hungarian Notation that most people recognise today - this is not how Hungarian Notation was designed and needs to be spelled out from word go. —The preceding unsigned comment was added by Andreas Toth (talk • contribs) 21:23, 19 March 2007 (UTC).

What, specifically, do you want to see changed in this article? Why do you not feel it adequately clarifies the different meanings? dr.ef.tymac 22:28, 19 March 2007 (UTC)

Tocright

Why's the TOC floating on the right? It's completely hidden from view. I'll remove the TOCright if nobody minds... Lucio 16:50, 17 May 2007 (UTC)

• Just done it. Lucio 14:27, 21 May 2007 (UTC)

"Notable Advocates" section

This section is, I think, pretty bad. There are a lot of problems with it.

• It's called "notable advocates", but contains both a for and against section. The against section should be called something else, and be a sibling. (I can't think of a word that's the opposite of an advocate and has the right shade of meaning.)
• The stuff in the "in favor" section doesn't have anything to do with notable advocates, and is just some opinion supporting it, so if it belongs at all, it needs to be in a different section.
• The stuff in the "in favor" section I think shouldn't even be there. It's non-verifiable, the opinion of one person (though probably shared by many, it's still opinion), and non-encyclopedic. It's also too informal.
• Both sections need to be expanded

Long story short, unless I get people advocating differently, in a couple days I'm going to do the following:

• Split the Controversy section into three parts: Advantages, Disadvantages, and Notable Opinions.
• Move the list of bullet points for and against Hungarian notation currently directly under "controversy" into the appropriate section
• Put the "in favor" part into the advantages section and clean it up
• Put the Linus quote into the notable opinions section

And some time after that I'm just going to delete the part that's currently under "in favor". EvanED 05:10, 11 August 2007 (UTC)

Nonsensical argument

"But imagine the logic below without Hungarian notation. (hMem = Handle memory, pMem = actual Pointer, where a handle is locked before getting the memory address)."

The language in this argument is awfully opinionated. I have no problem imagining the code without Hungarian notation. I don't even see what the argument is responding to with "But".

You don't need prefix-based Hungarian Notation to clarify closely-related variables. How about memHandle and memPointer? Those are perfectly valid, semantic variable names that do the same job. Plus they are self-documenting and no one had to explain what h and p mean. Using a prefix rather than a full word does not make the error any more obvious. In fact, it's easier for the eye to notice a word difference than a character difference. Some of what I just said is my own opinion, and I include it to point out that the matter at hand is just that: opinion.

This argument and example code do nothing to help describe Hungarian Notation. It's purely opinion, and a poorly authored one. I'm going to remove it entirely. —Preceding unsigned comment added by 147.177.47.147 (talk) 20:20, 29 May 2008 (UTC)

Why {{Expand-section}} Notable opinions?

Why is

{{Expand-section|date=June 2008}}

present on the "Notable opinions" section? The four opinions present fairly cover the universe of views on the subject. The only opinion I could see being added is that of somebody dicing why someone else' opinion is incorrect, but even that result is implicit when the four opinions presented are considered together. Of course, there may exist better statements of the views, but I don't think {{Expand-section}} will summon them.

While I don't outright reject the possibility that there could be a relevant point of view not already represented, I doubt it and see no need to call for more text in this section. Unless someone outlines the sort of view(s) as yet unrepresented under "Notable opinions," I'm going to remove the template shortly. —Christian Campbell 07:01, 23 June 2008 (UTC)

I removed it. —Christian Campbell 01:35, 27 June 2008 (UTC)

Another case

There is a custom in GUI programming, at least with Delphi, to use something like H.N. to mark component (widget) types. An example would be: lblUser (label), edtUser (editbox), btnAddUser (button). It seems similar to H.N., but I'm not sure does it count as it (it does sort of define the data type, though). Are there perhaps some other terms for such use? arny (talk) 08:49, 5 October 2009 (UTC)

m_ and g_ prefixes are not Hungarian notation until someone finds a source stating otherwise

Hungarian notation has, since Petzold and Win32 GUI code made it somewhat widespread, referred to affixing characters to the beginning of variable names to indicate information about their types. This is entirely different from the OOP concept of affixing m_ and g_ prefixes to indicate information about their scope, and also employing the underscore. Unless the first person that used that notation called it Hungarian then I really don't see the similarity, unless we'd like to redefine Hungarian notation to be any mnemonic of one or more characters affixed to the beginning of a variable name; I don't see how Wiki authors alone have the authority to do that.

Please cite a relevant source - a language author like Bjarne Stroustrup or similar - referring to the m_ and g_ prefixes as Hungarian, and before the existence of this Wiki page, or I'm going to remove it.Gameforge (talk) 23:56, 23 March 2011 (UTC)

Edit by above author: Bjarne himself doesn't recommend Hungarian, but seems largely unaware that scope prefixes are ever considered Hungarian: http://www2.research.att.com/~bs/bs_faq2.html#HungarianGameforge (talk) 23:56, 23 March 2011 (UTC)

Edit2: further contempt from Bjarne: "Hungarian notation - a coding convention that encodes type information in variable names. Its main use is to compensate for lack of type checking in weakly-typed or untyped languages. It is totally unsutable for C++ where it complicates maintenance and gets in the way of abstraction."

This is from http://www2.research.att.com/~bs/glossary.html and is in addition to the other contempt from Bjarne already seen below on this page. m_ and g_ notation is not considered "Hungarian", by anyone except Wiki authors apparently.Gameforge (talk) 23:56, 23 March 2011 (UTC)

they are Example99 (talk) 17:29, 21 February 2023 (UTC)

History

A history section is pretty useless without dates. — Preceding unsigned comment added by 203.41.222.1 (talk) 02:36, 25 May 2011 (UTC)

Tim Ottinger?

Who is Tim Ottinger and why is he notable? Binkyuk (talk) 17:55, 25 July 2011 (UTC)

This guy: C2 wiki page, blog --82.36.30.173 (talk) 05:53, 13 February 2012 (UTC)

Robert C. Martin (AKA "Uncle Bob") referenced Tim Ottinger's naming rules at Coding a Better World Together - with Uncle Bob - Day 1 (at 3 h 32 min 56 secs) --Mortense (talk) 21:58, 18 September 2019 (UTC)

Developer since 1979, a coach, trainer, and consultant with Industrial Logic. Writing credits in Clean Code, AgileInAFlash, Clean Agile, and various magazine articles.

Has been recognized for work in C++, Object-Oriented Design, XP, and agile coaching.

Frequent conference keynote speaker and podcast guest.

Same quote, two people?

Both "Robert_C._Martin [sic]" and Tim Ottinger have the same quote attributed to them. That certainly cannot be right. Who actually said it? Seems likely to have been Robert C. Martin, since the citation for Ottinger leads to Martin's book, but I don't actually have the book to check. Since this page doesn't seem to be getting a lot of attention, for now I'll be bold and remove the attribution to Ottinger. --134.74.17.96 (talk) 23:19, 26 June 2012 (UTC)

Chapter 2 of Clean Code lists author as "Tim Ottinger" in the upper-right corner of the first page. Clean code is an anthology of sorts. Authors' names are listed whenever the author of the chapter is not Robert C Martin. — Preceding unsigned comment added by 73.168.1.104 (talk) 15:42, 21 July 2020 (UTC)

window dimensions, bad example?

I can't see the point in the example heightWindow = window.getWidth()... both height and width are dimensions, so there's no problem in the cited code, I can easily imagine situations where it's not a mistake. In fact is heightWindow really hungarian? Wouldn't hungarian either prefix it with a dimension prefix, a unit prefix (inch, cm, pixel,...) or a type prefix (byte, long, integer,...)? (BTW, I'm not really sure about this, because frankly the article is kind of a mess, I mean, I came in with some idea about hungarian but now I'm more confuse than anything else) -- Jrob kiwi (talk) 13:00, 18 April 2013 (UTC)

Style guides

A list of notable style guides which support or disallow Hungarian would be well at home in this article. — Preceding unsigned comment added by Fulldecent (talk • contribs) 14:05, 10 July 2020 (UTC)

FileMaker example out of place?

The last item in the Disadvangages section reads as a different style than the rest, and essentially seems to serve as an advertisement for the FileMaker program. The citation points to the product page for the program, which doesn't include information relevant to the article. passcod (talk) 01:42, 14 November 2024 (UTC)

In fact the entire item seems redundant with the above item on code editor completion. Removing. passcod (talk) 01:44, 14 November 2024 (UTC)