Last Revision — April 19, 2022
2 Min Read
"Set" Method returns "Get" Method does not Return "Get" Method - More than an Accessor "Is" Method - More than a Boolean Expecting but not getting a collection Expecting but not getting a single instance Not answered question Validation method does not confirm Use Standard Nomenclature Where Possible
Lexical Abusers
Names
Within a Class
- Fallacious Comment (family)
- Obscured Intent (family)
Marcel Jerzyk in thesis (2022):
"Code Smells: A Comprehensive Online Catalog and Taxonomy"
Venera Arnaoudova in paper (2015):
"Linguistic Antipatterns: What they are and how developers perceive them"
Robert C. Martin in book (2008):
"Clean Code: A Handbook of Agile Software Craftsmanship"
When I started to think of Code Smells from the comprehensibility perspective (of its lack of) as one of the critical factors, I was pretty intrigued that it was not yet thoroughly researched, or at least not when researching with a focus on "Code Smell" as a keyword. There is a grounded idea about code that is obfuscated from the point of Obscured Intentions or code without any explanation (Magic Number, Uncommunicative Name). I felt like there was a missing hole in the code that was intentionally too clever (Clever Code) or the code that contradicts itself. Fortunately, I have found a fantastic article that supports my thoughts and addresses some of what I had in mind under the name Linguistic Antipatterns [1]. I have included their subset of antipatterns under one code smell because listing them one by one would be too granular from a code perspective. The idea behind them can be summarized by one name: Fallacious Method Name.
This smell is caused by creating conflicting methods or functions regarding their functionality and naming. Over the years, programmers have developed connections between certain words and functionality that programmers should tie together. Going against logical expectations by, for example, creating a getSomething
function that does not return is confusing and wrong.
When we create methods, their name may not entirely represent what they will be doing after we finish working on them. Except that one should then go back and correct its name accordingly to what has been done.
Developers need to inspect the function or methods to determine what they do.
If someone would like to use a method with a given name, he should also expect the name's effect.
def getFoos() -> Foo:
...
foo: Foo = ...
return foo
def isGoo() -> str:
...
return 'yes'
def setValue(self, value) -> Any:
...
return new_value
def getFoos() -> list[Foo]:
...
foos: list[Foo] = ...
return foos
def isGoo() -> bool:
...
return True
def setValue(self, value) -> None:
...