Editing Hungarian notation (section)

==Notable opinions==
* [[Robert Cecil Martin]] (against Hungarian notation and all other forms of encoding): <blockquote>... nowadays HN and other forms of type encoding are simply impediments.  They make it harder to change the name or type of a variable, function, member or class.  They make it harder to read the code. And they create the possibility that the encoding system will mislead the reader.<ref>{{cite book
 |       last = Martin |first=Robert Cecil 
 |       date = 2008
 |      title = Clean Code: A Handbook of Agile Software Craftsmanship
 |   location = Redmond, WA
 |  publisher = Prentice Hall PTR
 |       isbn = 978-0-13-235088-4
}}</ref></blockquote>
* [[Linus Torvalds]] (against Systems Hungarian): <blockquote>Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged—the compiler knows the types anyway and can check those, and it only confuses the programmer.<ref>{{cite web
 |      title = Linux kernel coding style
 |       work = [[Linux kernel]] documentation
 |        url = https://www.kernel.org/doc/html/v4.10/process/coding-style.html
 | access-date = 9 March 2018
}}</ref></blockquote>
* [[Steve McConnell]] (for Apps Hungarian): <blockquote>Although the Hungarian naming convention is no longer in widespread use, the basic idea of standardizing on terse, precise abbreviations continues to have value. Standardized prefixes allow you to check types accurately when you're using abstract data types that your compiler can't necessarily check.<ref>{{cite book
 |       last = McConnell |first=Steve |author-link=Steve McConnell
 |       date = 2004
 |      title = [[Code Complete]]
 |    edition = 2nd
 |   location = Redmond, WA
 |  publisher = [[Microsoft Press]]
 |       isbn = 0-7356-1967-0
}}</ref></blockquote>
* [[Bjarne Stroustrup]] (against Systems Hungarian for C++):<blockquote>No I don't recommend 'Hungarian'. I regard 'Hungarian' (embedding an abbreviated version of a type in a variable name) as a technique that can be useful in untyped languages, but is completely unsuitable for a language that supports generic programming and object-oriented programming — both of which emphasize selection of operations based on the type and arguments (known to the language or to the run-time support). In this case, 'building the type of an object into names' simply complicates and minimizes abstraction.<ref>{{cite web
 |       last = Stroustrup |first=Bjarne |author-link = Bjarne Stroustrup
 |       date = 2007
 |      title = Bjarne Stroustrup's C++ Style and Technique FAQ
 |        url = http://www.stroustrup.com/bs_faq2.html#Hungarian
 | access-date = 15 February 2015
}}</ref></blockquote>
* [[Joel Spolsky]] (for Apps Hungarian): <blockquote>If you read Simonyi's paper closely, what he was getting at was the same kind of naming convention as I used in my example above where we decided that <code>'''us'''</code> meant unsafe string and <code>'''s'''</code> meant safe string. They're both of type <code>'''string'''</code>. The compiler won't help you if you assign one to the other and Intellisense [an [[intelligent code completion]] system] won't tell you [[:wikt:bupkis#English|bupkis]]. But they are semantically different. They need to be interpreted differently and treated differently and some kind of conversion function will need to be called if you assign one to the other or you will have a runtime bug. If you're lucky. There's still a tremendous amount of value to Apps Hungarian, in that it increases collocation in code, which makes the code easier to read, write, debug and maintain, and, most importantly, it makes wrong code look wrong.... (Systems Hungarian) was a subtle but complete misunderstanding of Simonyi’s intention and practice.<ref name="Spolsky">{{cite web
 |       last = Spolsky |first=Joel |author-link = Joel Spolsky
 |       date = 2005-05-11
 |      title = Making Wrong Code Look Wrong
 |       work = Joel on Software
 |        url = http://www.joelonsoftware.com/articles/Wrong.html
 | access-date = 2005-12-13
 }}</ref></blockquote>
* [[Microsoft]]'s Design Guidelines<ref name=MSDotNetDeveloperGuide>{{cite web
 |      title = Design Guidelines for Developing Class Libraries: General Naming Conventions
 |        url = http://msdn2.microsoft.com/en-us/library/ms229045.aspx
 | access-date = 2008-01-03
}}</ref> discourage developers from using Systems Hungarian notation when they choose names for the elements in .NET class libraries, although it was common on prior Microsoft development platforms like [[Visual Basic (classic)|Visual Basic 6]] and earlier.  These Design Guidelines are silent on the naming conventions for local variables inside functions.