Talk:Hungarian notation

message: 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)
replies: text: 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)
thread_title:  To be corrected 

message: 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)
replies: text: 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)
thread_title:  Brain damaged 

message: 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)
thread_title:  C or BCPL? 

message: 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)
replies: text: all the objections are just 4 systems Example99 (talk) 17:28, 21 February 2023 (UTC)
thread_title:  Nearly all Examples in article are bogus examples of Apps Hungarian 

message: 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)
replies: text: 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)
thread_title:  Clarification of the use of "type" needed 

message: 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)
thread_title:  Tocright 

message: 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)
thread_title:  "Notable Advocates" section 

message: "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)
thread_title:  Nonsensical argument

message: Why is

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  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)
replies: text: I removed it. —Christian Campbell 01:35, 27 June 2008 (UTC)
thread_title:  Why <nowiki>{{Expand-section}}</nowiki> Notable opinions? 

message: 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)
thread_title:  Another case 

message: 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)
replies: text: they are Example99 (talk) 17:29, 21 February 2023 (UTC)
thread_title:  m_ and g_ prefixes are not Hungarian notation until someone finds a source stating otherwise 

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

message: Who is Tim Ottinger and why is he notable? Binkyuk (talk) 17:55, 25 July 2011 (UTC)
replies: text: This guy: C2 wiki page, blog --82.36.30.173 (talk) 05:53, 13 February 2012 (UTC)

text: 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)
thread_title:  Tim Ottinger? 

message: 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)
thread_title:  Same quote, two people? 

message: 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)
thread_title:  window dimensions, bad example? 

message: 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)
thread_title:  Style guides