This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
*It encourages the use of poor naming practices. For example it becomes confusing when it is used to represent several properties, as in:
a_crszkvc30LastNameCol : constant reference function argument, holding contents of a database column of type varchar(30) called LastName that was part of the table's primary key
* It is inconsistent with code portability since the variable name is tied to the type. A particularly well known example is the standard WPARAM type, and the accompanying wParam formal parameter in many Windows system function declarations. It was originally a 16 bit type, but was changed to a 32 bit or 64 bit type in later versions of the operating system while retaining its original name (its true underlying type is UINT_PTR, that is, an unsigned integer large enough to hold a pointer). * It dramatically reduces readability for those unfamiliar with the notation * Modern Integrated development environments will automatically flag operations which use incompatible types, and display variable types on demand; making the notation obsolete. * It may lead to inconsistency when code is modified. If a variable's type is changed, its name may reflect the previous type, leading to confusion.
The very existence of flamethrowers proves that at some time, some where, some place, someone once said to themselves "I'd really like to set those people on fire over there, but I just can't get close enough".