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)[reply]

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)[reply]

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)[reply]

Blight

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

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)[reply]

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)[reply]

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.

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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).[reply]
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:

define CLC short // type declaration for a class code, an integer index into the institution's master course catalog
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)[reply]

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

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)[reply]

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).[reply]

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)[reply]

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)[reply]

Just done it. Lucio 14:27, 21 May 2007 (UTC)[reply]

"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)[reply]