Code Smell — Practical Guide using .Net Core Part-I

9 min readJan 13, 2024

What constitutes Code Smell?

Code smells serve as evident signs within the codebase, pointing to deeper issues in the application’s design or the overall code structure. While they may not manifest as bugs or errors, these discernible and observable breaches in fundamental code design and development principles have the potential to compromise code quality and accumulate technical debt over time. Although the code remains functional and adheres to its expected performance, the presence of code smells hinders the development process and exposes the program to potential performance and security vulnerabilities down the line. Essentially, code smells act as indicators revealing the root problems contributing to the accrual of technical debt in the codebase.

Therefore, delving into these code smells demands thorough investigation and frequently exposes critical issues in the code that necessitate prompt resolution. To pinpoint code smells and address the root problem effectively, it is crucial to possess a detailed understanding of various types of code smells and adhere to best practices to prevent their occurrence. This story will comprehensively explore key topics related to code smells, offering insights into identification, underlying issues, and preventive measures.

Typical Code Smell Varieties and Techniques for Recognition

Code smells typically emerge when developers deviate from adhering to design principles and standards.

Factors such as tight deadlines, lack of experience, and the omission of code reviews contribute to mistakes in code development, resulting in the manifestation of code smells. These issues vary widely between projects, developers, and businesses. Therefore, it is essential to fully comprehend the organization’s design and development standards before addressing any code smells.

This article outlines the most prevalent code smells to assist you in enhancing your code quality. Detailed explanations, examples, and solutions for some of these code smells are covered in this story, with the remaining ones discussed in subsequent stories.

Long Method:
Symptom: A method that is too long, making it harder to understand and maintain.

Solution: Break the method into smaller, more focused methods.
Large Class:
Symptom: A class that has grown too large and handles multiple responsibilities.

Solution: Apply the Single Responsibility Principle (SRP) and break down large classes into smaller, focused ones.
Duplicate Code:
Symptom: Repeated code blocks in different parts of the application.

Solution: Extract common functionality into methods or classes to avoid redundancy.
Long Parameter List:
Symptom: Methods with a large number of parameters, making them hard to understand and use.

Solution: Use objects or structures to group related parameters, or consider using method overloading.
Feature Envy:
Symptom: A method that seems more interested in the data of another class than its own.

Solution: Move the method to the class that holds the data it is interested in.
Inconsistent Naming:
Symptom: Methods, variables, or classes with inconsistent or unclear names.

Solution: Use clear and consistent naming conventions to improve code readability.
Too Many Comments:
Symptom: Excessive comments that might indicate code is not self-explanatory.

Solution: Improve code clarity and structure to reduce the need for excessive comments.
Switch Statements:
Symptom: Multiple switch or if-else statements that can indicate a lack of polymorphism.

Solution: Use polymorphism or strategy pattern to handle different cases.
Data Clumps:
Symptom: Groups of parameters that appear together in multiple places.

Solution: Encapsulate related parameters into a single object or class.
Shotgun Surgery:
Symptom: A small change in one part of the codebase requires changes in many other places.

Solution: Refactor code to reduce dependencies and improve modularity.
Lazy Class:
Symptom: Classes that don’t do much and have few responsibilities.

Solution: Consider merging, extracting, or redefining the responsibilities of such classes.
Speculative Generality:
Symptom: Adding flexibility for potential future needs that may never arise.

Solution: Remove unnecessary abstractions and keep the code simple until flexibility is genuinely needed.

Lets explore code smells through illustrative examples to gain a comprehensive understanding.

1. Long Method

The “Long Method” code smell refers to a method that has become excessively long, making it challenging to understand, maintain, and debug. Long methods are often an indication that a function is trying to do too much and violates the Single Responsibility Principle. Here’s an example of a long method in .NET Core and a refactoring solution:

Smelly Code:

public class OrderProcessor
{
    public void ProcessOrder(Order order)
    {
        // Step 1: Validate order
        if (order.IsValid())
        {
            // Step 2: Calculate order total
            decimal orderTotal = CalculateOrderTotal(order);

            // Step 3: Apply discounts
            ApplyDiscounts(order, orderTotal);

            // Step 4: Update inventory
            UpdateInventory(order);

            // Step 5: Send confirmation email
            SendConfirmationEmail(order);
        }
        else
        {
            // Handle invalid order
            LogInvalidOrder(order);
        }
    }

    private decimal CalculateOrderTotal(Order order)
    {
        // Complex logic for calculating the order total
        // ...
    }

    private void ApplyDiscounts(Order order, decimal orderTotal)
    {
        // Logic for applying discounts
        // ...
    }

    private void UpdateInventory(Order order)
    {
        // Logic for updating inventory
        // ...
    }

    private void SendConfirmationEmail(Order order)
    {
        // Logic for sending confirmation email
        // ...
    }

    private void LogInvalidOrder(Order order)
    {
        // Log details of an invalid order
        // ...
    }
}

Better Approach:

public class OrderProcessor
{
    public void ProcessOrder(Order order)
    {
        if (!order.IsValid())
        {
            HandleInvalidOrder(order);
            return;
        }

        decimal orderTotal = CalculateOrderTotal(order);
        ApplyDiscounts(order, orderTotal);
        UpdateInventory(order);
        SendConfirmationEmail(order);
    }

    private void HandleInvalidOrder(Order order)
    {
        // Handle invalid order
        LogInvalidOrder(order);
    }

    private decimal CalculateOrderTotal(Order order)
    {
        // Calculate order total
        // ...
    }

    private void ApplyDiscounts(Order order, decimal orderTotal)
    {
        // Apply discounts
        // ...
    }

    private void UpdateInventory(Order order)
    {
        // Update inventory
        // ...
    }

    private void SendConfirmationEmail(Order order)
    {
        // Send confirmation email
        // ...
    }

    private void LogInvalidOrder(Order order)
    {
        // Log details of an invalid order
        // ...
    }
}

In this refactoring, the ProcessOrder method has been simplified by extracting the logical steps into separate private methods. Each private method now represents a specific responsibility, making the code more modular and easier to understand. Additionally, it adheres to the Single Responsibility Principle by ensuring that each method has a clear and specific purpose.

2. Large Class

In the context of .NET Core, a “Large Class” code smell typically refers to a class that has grown too large and is attempting to handle multiple responsibilities. Large classes can become hard to understand, maintain, and extend. They violate the Single Responsibility Principle (SRP) and can lead to code that is difficult to test and refactor. Here’s an example of a large class in .NET Core and a refactoring suggestion:

Smelly Code:

public class DataProcessor
{
    private List<string> data;

    public DataProcessor(List<string> inputData)
    {
        data = inputData;
    }

    public void ProcessData()
    {
        // ... a lot of code here ...
        // ... handling data processing ...
        // ... interacting with external services ...
        // ... validation logic ...
        // ... more responsibilities ...
    }
}

Batter Approach:

public class DataProcessor
{
    private List<string> data;

    public DataProcessor(List<string> inputData)
    {
        data = inputData;
    }

    public void ProcessData()
    {
        // ... data processing logic ...
        ProcessExternalServices();
        ValidateData();
        // ... more responsibilities ...
    }

    private void ProcessExternalServices()
    {
        // ... logic for interacting with external services ...
    }

    private void ValidateData()
    {
        // ... validation logic ...
    }
}

In the improved code:

Responsibilities Separation: The original ProcessData method, which was doing a lot of things, has been refactored to delegate specific responsibilities to private methods.
Single Responsibility: Each private method now has a specific responsibility. For example, ProcessExternalServices handles interactions with external services, and ValidateData is responsible for data validation.
Readability and Maintainability: Breaking down the large method into smaller, focused methods enhances code readability and makes it easier to maintain.

Remember, the goal is to have classes that are cohesive and follow the Single Responsibility Principle. Regular code reviews and refactoring are essential to keep the codebase clean and maintainable.

3. Duplicate Code

The Duplicate Code code smell refers to the presence of identical or nearly identical code segments in different parts of your application. This redundancy can lead to maintenance challenges, as any changes or bug fixes need to be applied consistently across all instances of the duplicated code. In .NET Core, you can use various techniques and tools to identify and address duplicate code. Here are some strategies:

Smelly Code
1. Extract Common Functionality:
Identify duplicated code segments and extract them into a separate method or function. This way, you centralize the logic and avoid redundancy.

// Duplicated code
public void ProcessDataA()
{
    // ... common code ...
}

public void ProcessDataB()
{
    // ... common code ...
}

// Refactored code
public void ProcessDataCommon()
{
    // ... common code ...
}

public void ProcessDataA()
{
    ProcessDataCommon();
    // ... specific code for A ...
}

public void ProcessDataB()
{
    ProcessDataCommon();
    // ... specific code for B ...

2. Create Helper Classes or Modules
If the duplicated code is more extensive, consider creating a helper class or module that encapsulates the common functionality.

// Duplicated code in different classes
public class ClassA
{
    public void ProcessDataA()
    {
        // ... common code ...
    }
}

public class ClassB
{
    public void ProcessDataB()
    {
        // ... common code ...
    }
}

// Refactored code
public class CommonProcessor
{
    public void ProcessData()
    {
        // ... common code ...
    }
}

public class ClassA
{
    public void ProcessDataA()
    {
        CommonProcessor.ProcessData();
        // ... specific code for A ...
    }
}

public class ClassB
{
    public void ProcessDataB()
    {
        CommonProcessor.ProcessData();
        // ... specific code for B ...
    }

3. Leverage Inheritance and Polymorphism:
If duplicated code involves similar behavior in different classes, consider using inheritance and polymorphism.

// Duplicated code in different classes
public class ClassA
{
    public void ProcessData()
    {
        // ... common code ...
    }
}

public class ClassB
{
    public void ProcessData()
    {
        // ... common code ...
    }
}

// Refactored code
public abstract class BaseClass
{
    public void ProcessData()
    {
        // ... common code ...
    }
}

public class ClassA : BaseClass
{
    // ... specific code for A ...
}

public class ClassB : BaseClass
{
    // ... specific code for B ...
}

4. Use Static Analysis Tools:
Take advantage of static analysis tools like ReSharper, SonarQube, or Visual Studio’s built-in code analysis to automatically identify and highlight duplicate code segments in your .NET Core project.

By addressing Duplicate Code code smells, you improve code maintainability, reduce the risk of introducing bugs during updates, and enhance overall code quality. Regular code reviews and continuous refactoring are essential practices to keep your codebase clean and efficient.

4. Long Parameter List

The “Long Parameter List” code smell occurs when a method has an excessive number of parameters, making it challenging to understand and maintain. In .NET Core, this can be addressed using various techniques to improve code readability and maintainability. Here’s an example and some potential solutions:

Smelly Code

public class DataProcessor
{
    public void ProcessData(string input1, int input2, DateTime input3, bool input4, double input5, string input6, int input7)
    {
        // ... method implementation ...
    }
}

Potential Solutions:
1. Group Related Parameters:
Identify parameters that logically belong together and group them into a single object or class.

public class Data
{
    public string Input1 { get; set; }
    public int Input2 { get; set; }
    public DateTime Input3 { get; set; }
    // ... other properties ...
}

public class DataProcessor
{
    public void ProcessData(Data data)
    {
        // ... method implementation ...
    }
}

2. Use Method Overloading:
If some parameters are optional or have default values, consider using method overloading.

public class DataProcessor
{
    public void ProcessData(string input1, int input2, DateTime input3)
    {
        // ... method implementation ...
    }

    public void ProcessData(string input1, int input2, DateTime input3, bool input4, double input5, string input6, int input7)
    {
        // ... method implementation ...
    }
}

3. Use Method Overloading:
If the number of parameters is necessary, consider using the builder pattern to construct an object with a fluent interface.

public class DataProcessor
{
    public void ProcessData(DataBuilder builder)
    {
        Data data = builder.Build();
        // ... method implementation ...
    }
}

public class DataBuilder
{
    // ... properties for each parameter ...

    public Data Build()
    {
        // ... construct and return Data object ...
    }
}

4. Encapsulate Parameters:
If the duplicated code is more extensive, consider creating a helper class or module that encapsulates the common functionality.

public class Data
{
    public string Input1 { get; set; }
    public int Input2 { get; set; }
    public DateTime Input3 { get; set; }
    // ... other properties ...
}

public class DataProcessor
{
    public void ProcessData(Data data)
    {
        // ... method implementation ...
    }
}

By applying these techniques, we can improve the organization and readability of our code, making it easier to understand and maintain, even when dealing with methods that require multiple parameters.

In this narrative, we delved into the manifestations of code smells such as Long Method, Large Class, Duplicate Code, and Long Parameter List. The subsequent segment will encompass the remaining ones as a part of this story.