Overview
Whenever a variable has an explicit type prefix or suffix, it can strongly signal that it should be just a class of its own. For example, current_date = "2021-14-11", embeds the potential class Date in the name of a variable, and that could also be classified as the Primitive Obsession code smell.
Wake signals that the embedded type could also be in the method names, giving an example of a schedule.add_course(course) function in contrast to schedule.add(course). He notes that it could have been a matter of preference, although he insists that this can be a problem wherever some generalization occurs [1]. When a parent class for Course is introduced to cover not only courses but also series of courses, then add_course() has a name that is no longer appropriate, thus suggesting the usage of more neutral terms. [1] Parameters of a method are part of the method name, and this kind of naming is also a duplication.
With all the possibilities of annotating variables, it is unnecessary to mention it twice through variable name when type annotation or type hinting is present. Names with embedded types in them, for which no class yet could represent them, are good candidates to be refactored into separate classes.
Causation
This was a standard in pointer-based languages, but it is not helpful in modern Object-Oriented Programming languages. [1]
Problems
Both the argument and name mentions the same type.
If the name of a variable is just precisely the name of the class, it's a case of Uncommunicative Name.
Example
1player_name: str = "Luzkan"
2player_health: int = 100
3player_stamina: int = 50
4player_attack: int = 71datetime = datetime.datetime.now()
2foo()
3datetime_2 = datetime.datetime.now()Refactoring
- Extract Class
- Rename Method
- Rename Variable
Sources
- ORIGIN2004 · ISBN 978-0321109293