Names (Refactoring Work Book)

Smell Covered

l         Type Embedded in Name (including Hungarian)

l         Uncommunicative Name

l         Inconsistent Names

Type Embedded in Name (Including Hungarian)

Symptoms

l         Names are compound words, consisting of a word plus the type of the argument(s). For example, a method addCourse(Course c).

l         Names are in Hungarian notation, where the type of an object is encoded into the name; e.g., iCount as an integer member variable.

l         Variable names reflect their type rather than their purpose or role.

How It Got This Way

The type may be added in the name of communication. For example, schedule.addCourse(course) might be regarded as more readable than schedule.add(course). (I don’t think it is, but some do.)

The embedded type name represents duplication: Both the argument and the name mention the same type. The embedded name can create unnecessary troubles later on. For example, suppose we introduce a parent class for Course to cover both courses and series of courses. Now , all the places that refer to addCourse() have a name that’s not quite appropriate. We either change the name at every call site or live with a poor name. Finally, by naming things for the operation alone, we make it easier to see duplication and recognize new abstractions.

Hungarian notation is often introduced as part of a coding standard. In pointer-based languages(like C), it was useful to know that **ppc is in fact a character, but in object oriented languages it overcouples a name to its type.