Difference between revisions of "Avoid encodings: Hungarian Notation"

From Basef
Jump to: navigation, search
 
Line 1: Line 1:
 +
Java programmers don’t need type encoding. Objects are strongly typed, and editing
 +
environments have advanced such that they detect a type error long before you can run a
 +
compile! So 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, or class. They
 +
make it harder to read the code. And they create the possibility that the encoding system
 +
will mislead the reader.
 +
 
Examples of Hungarian Notation:
 
Examples of Hungarian Notation:
  

Latest revision as of 12:15, 27 January 2020

Java programmers don’t need type encoding. Objects are strongly typed, and editing environments have advanced such that they detect a type error long before you can run a compile! So 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, or class. They make it harder to read the code. And they create the possibility that the encoding system will mislead the reader.

Examples of Hungarian Notation:

  • lAccountNum : variable is a long integer ("l");
  • arru8NumberList : variable is an array of unsigned 8-bit integers ("arru8");
  • bReadLine(bPort,&arru8NumberList) : function with a byte-value return code.
  • strName : Variable represents a string ("str") containing the name, but does not specify how that string is implemented.
  • rwPosition : variable represents a row ("rw");
  • usName : variable represents an unsafe string ("us"), which needs to be "sanitized" before it is used (e.g. see code injection and cross-site scripting for examples of attacks that can be caused by using raw user input)
  • szName : variable is a zero-terminated string ("sz"); this was one of Simonyi's original suggested prefixes.
  • pX is a pointer to another type X; this contains very little semantic information.
  • d is a prefix meaning difference between two values; for instance, dY might represent a distance along the Y-axis of a graph, while a variable just called y might be an absolute position. This is entirely semantic in nature.
  • sz is a null- or zero-terminated string. In C, this contains some semantic information because it is not clear whether a variable of type char* is a pointer to a single character, an array of characters or a zero-terminated string.
  • w marks a variable that is a word. This contains essentially no semantic information at all, and would probably be considered Systems Hungarian.
  • b marks a byte, which in contrast to w might have semantic information, because in C the only byte-sized data type is the char, so these are sometimes used to hold numeric values. This prefix might clear ambiguity between whether the variable is holding a value that should be treated as a character or a number.

Examples related to type:

  • bBusy : boolean
  • chInitial : char
  • cApples : count of items
  • dwLightYears : double word (Systems)
  • fBusy : flag (or float)
  • nSize : integer (Systems) or count (Apps)
  • iSize : integer (Systems) or index (Apps)
  • fpPrice: floating-point
  • dbPi : double (Systems)
  • pFoo : pointer
  • rgStudents : array, or range
  • szLastName : zero-terminated string
  • u16Identifier : unsigned 16-bit integer (Systems)
  • u32Identifier : unsigned 32-bit integer (Systems)
  • stTime : clock time structure
  • fnFunction : function name
  • pszOwner : pointer to zero-terminated string
  • rgfpBalances : array of floating-point values
  • aulColors : array of unsigned long (Systems)