Code Smells (Part one)

Code Smells term didn’t really go official though until Martin Fowler & Kent Beck published their book,
“Refactoring: Improving the Design of Existing Code”

Code smells were defined by Kent Beck in Fowler’s book as a means to diagnose symptoms that may be indicative of something wrong in the system code. They refer to any symptom in the source code of a program that possibly indicates a deeper problem. we can break down this topic to levels, Method Level, Class Level, Application Level, Design Level.

In this article, I will focus on “Method level” topic

• What is code smells?
• How to define the code smell in the method level?

What is Code Smells? 🌋

Code smells are not bugs, compiler errors, or broken or nonfunctional code. code smells are certain structures that indicate a violation of fundamental design principles and negatively impact design quality.

Method Level Smells

in this area most of code smells coming due to naming conventions and bloated content.

Too many parameters: 💥

A long list of parameters is hard to read and makes calling and testing the function complicated. It may indicate that the purpose of the function is ill-conceived and that the code should be refactored so the responsibility is assigned in a more clean-cut way.

fun registerNewUser( firstName: String, lastName: String, birthDate: String, gender: String, email: String, mobileNumber: String, country: String) {
...
}

Solution: group the parameters into common data grouping, in this case, we can make it like that

data class User(
    val firstName: String,
    val lastName: String,
    val birthDate: String,
    val gender: String,
    val email: String,
    val mobileNumber: String,
    val country: String
)

then our registration method will be

fun registerNewUser(user: User) {
    ...
}

Long method: 💥

Any method should only be responsible for single behavior not many. such a term we call as Bloated Method which is a method contain many actions in a single function.

Split down the Bloated Method into single-action methods

When it is difficult to come up with a meaningful name for the function (It is probably doing too much). break Bloated Method into new functions which make all of them more maintainable and use meaningful names for the new functions.

Excessively long identifiers: 💥

in particular, the use of naming conventions to provide disambiguation that should be implicit in the software architecture.

numberOfCharInExpressiveWord is a very long name and even not clear, this is a sign of code smell

Excessively short identifiers: 💥

the name of a variable should reflect its function unless the function is obvious.

i,j,k,m,S is not a clear name for variables, and it’s methods or loops, this is a sign of code smell

Always use a clear name that describes its job.

Excessive return of data: 💥

A function or method that returns more than what each of its caller's needs. if you expect a string return from your method, don’t return the entire loaded object.

fun calculateUserAge(birthDate: Date): User {
    .....
    return user
}

we should only return user age as a number not entire.

Longline of code (or God Line): 💥

How many times did you catch too long line with more than one call, or a line which you have to scroll horizontally to catch its end, such a line we call it as God Line I guess such a line should be named as Devil line which makes the code difficult to read, understand, debug, refactor, or even identify possibilities of software reuse. Example:

God lines are an indicator for readability issue, you shouldn’t make any line exceed the limit of wrapper hint

keep your code formatted with line break limit.

Resources:

bliki: CodeSmell

Sharpen your sense of (code) smell - .NET Tools Blog