Aware of the code smells!

-

 The first step to achieve clean code is detecting code smells.


If you are not aware of this topic Code Smells, you can wonder how a code will stink. How do we smell that.

Haha, No it's not actually the smell

Code smells refer to any symptom in the source code of a program that possibly indicates a deeper problem, hindering software maintenance and evolution.
Code smells may occur in various levels. Always this is quite challenging for developers to detect code smells.

But, If code smells are detected as earlier as possible, Development risks could be greatly reduced.

Code Smell may occur in

  • Variable Level
    • Primitive Obsession
  • Method level
    • Long Method
    • Long parameter lists
  • Class Level
    • Large Class
    • Temporary Fields
  • Sub Class Level
    • Refused Bequest
    • Similar Functionalities
  • Code Change Level
    • Change Preventers
    • Duplicate Code
    • Dead Code
    • Feature Envy


Primitive Obsession :


Primitive Obsession is a kind of code smell most of the developers are fed up with. There are not much easier to detect in the early stages.Primitives are basic data types like int,float,char,string etc..,Primitive Obsession is when the code relies too much on primitives.If primitives controls a logic in a class, they are not type safe.

Consider you are working on an authentication module with the following code

public boolean create(String UserName, String Password){
}


Here, consider the password field. There are lot of concerns for the password like it has to be more than a specific length, it should have capital letter, small letter , special characters etc..,Whether all this could be done inside a create() method, possibly `A Big No!`.
public boolean create(UserDTO userDTO){
}

This will be type safe now because, you don't have to worry about the password, when an object is created, it checks for the characteristics of password.

Long Methods:


There is a concept called 'Single Responsibility Principle'.Every method should be responsible for only one operation.

Look for the following example :
Input : Two numbers num1 and num2
Output : Find the greater number and print the greater number if its positive else print zero.


public void printGreaterNumber(int num1,int num2){
int greaterNumber;
if(num1>num2){
greaterNumber = num1;
}else{
greaterNumber = num2;
}
if(greaterNumber>0){
print(greaterNumber);
}else{
print("0");
}
}

The above code is understandable but not a clean code.While working on a project with bunch of files, this code stinks.


public int getGreaterNumber(int num1,int num2){
if(num1>num2)
return num1;
return num2;
}

public boolean isPositive(int num){
return num>=0;
}

public void printGreaterNumber(int num1,int num2){
int greaterNumber=getGreaterNumber(num1,num2);
if(isPositive(greaterNumber)){
print(greaterNumber);
}else{
print("0");
}
}


The above code is an example of clean code.

Long Parameter Lists:


Always having more fields in a parameter list is a symptom of code stink. This can be resolved by using Objects instead of parameter lists.

Large Class :


Similar to Large methods, Large Classes stink could be solved using Single Responsibility Principle. The data members and member functions of a class should be tightly relevant. Irrelevant or loosely relevant data members and member functions has to be moved out.

Temporary Fields:


The data members to which the values are not always assigned is a code stink.Some data members will receive values only during some cases. For example, Consider a PaymentPlan class. The plan of the users may be either trial or paid.Having a transactionID field inside the PaymentPlan class is assigned value for paid users but not for trial users.In these cases, You should design the class in such a way that these kind of transactionID fields are not present in the PaymentPlan class.The best refactoring for this is have parent class Plan and subclasses for Plan class as Trial and Paid. This will serve the purpose.

Refused Bequest:


If a subclass uses only some of the methods and properties inherited from its parents, the hierarchy is off-kilter. The unneeded methods may simply go unused or be redefined and give off exceptions.

Similar Functionalities:


If two subclasses contains member functions with different names doing the same purpose, then have it as a single function in the parent class.

Change Preventers:


There are some scenarios , where you need to change irrelevant codes while making changes in a particular part of code. This is a riskier code stink. Independent code has to be developed.This can be resolved by choosing the logical design while designing the structure of the class and picking the correct design patterns.

Duplicate Code:


Whenever you add a functionality, search whether the purpose is already served in your project. This eliminates duplicate code.

Dead Code:


Whenever a module goes out of scope, remove all its related functionalities in the code base.

Feature Envy:


A method accesses the data of another object more than its own data.This smell may occur after fields are moved to a data class. If this is the case, you may want to move the operations on data to this class as well.

Comments

Post a Comment