Navs
Code Smells Catalog
Fallacious Method Name

Last Revision — April 19, 2022

2 Min Read


  • Also Known As

    "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

  • Obstruction

    Lexical Abusers

  • Occurrence

    Names

  • Expanse

    Within a Class

  • Related Smells

    - Fallacious Comment (family)
    - Obscured Intent (family)

  • History

    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"

Fallacious Method Name

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.

Causation

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.

Problems

Decreased Readability

Developers need to inspect the function or methods to determine what they do.

Reduced Reliability

If someone would like to use a method with a given name, he should also expect the name's effect.

Example

Smelly

def getFoos() -> Foo:
    ...
    foo: Foo = ...
    return foo

def isGoo() -> str:
    ...
    return 'yes'

def setValue(self, value) -> Any:
    ...
    return new_value

Solution

def getFoos() -> list[Foo]:
    ...
    foos: list[Foo] = ...
    return foos

def isGoo() -> bool:
    ...
    return True

def setValue(self, value) -> None:
    ...

Refactoring:

  • Rename Method (to remove contradictions)

Sources
  • [Origin] - Marcel Jerzyk, "Code Smells: A Comprehensive Online Catalog and Taxonomy" (2022)
  • [Parentage1] - Venera Arnaoudova, Massimiliano Di Penta, Giuliano Antoniol "Linguistic Antipatterns: What they are and how developers perceive them" (2015)
  • [Parentage2] - Robert Martin, "Clean Code: A Handbook of Agile Software Craftsmanship" (2008)