What Are Code Smells?

Code smells are patterns in code that may indicate a deeper problem. They don’t break your program, but they often:

• Make the system harder to maintain
• Increase the risk of future bugs
• Complicated testing and debugging
• Cause failure under complex conditions

Refactoring

Refactoring involves enhancing a program’s internal structure while keeping its external behavior unchanged, making the code more readable and maintainable.
Code smells are signals that refactoring is needed.

Benefits of Refactoring

• Reduces code complexity
• Improves clarity and readability
• Makes future updates easier
• Helps enforce design principles
• Enables easier testing and debugging

Common Code Smells and How to Address Them

1. Excessive Comments

Comments are helpful when used appropriately, but too many comments may suggest that the code isn’t self-explanatory.

Bad Example:
python

# Calculate final price with tax
final_price = price * 1.18

Refactored:
python

final_price = calculate_price_with_tax(price)
def calculate_price_with_tax(price):
return price * 1.18

Use comments when:

• Explaining “why” something is done a certain way
• Clarifying complex or unusual logic
• Leaving notes for future improvements or fixes
• Highlighting assumptions (e.g., “user_data is already validated”)

Avoid comments like:
python

x = 5  # Set x to 5  # Obvious and unnecessary

2. Long Methods
A method that does too many things becomes difficult to read, test, and maintain.
Example of a long method:
python

def generate_report(data):
# Processes data, calculates stats, prints results
...

Refactored:
Break into focused helper methods:
python

def generate_report(data):
total, count, average = calculate_summary(data)
print_summary(total, count, average)
print_high_value_sales(data)
print_returns(data)

Each method now does one task, following the Single Responsibility Principle.

3. Long Parameter List
Functions that require many parameters can be confusing and error-prone.

Bad:
csharp

RegisterUser(string firstName, string lastName, string email, string phone, string address, DateTime dob, string password)

Improved:

• Use a data class

public void RegisterUser(UserRegistrationInfo info)

• Use optional parameters if applicable
• For more flexibility, apply the Builder Pattern

4. Large Class
A class handling too many responsibilities becomes hard to maintain.
Problematic Class:

public class Employee
{
// Manages data, business logic, reporting, and persistence
}

Refactored Approach:
Split into multiple classes:

• Employee: Data and business rules
• PayrollService: Handles salary calculations
• ReportingService: Generates reports
• EmployeeRepository: Manages database operations

This approach aligns with the Single Responsibility Principle.

5. Inconsistent Naming
Poor naming conventions reduce readability and introduce confusion.
Bad Example:

public class emp { public int id; public string name; }

Improved:

public class Employee

{
public int EmployeeId { get; set; }
public string FullName { get; set; }
}

Recommended Naming Conventions:

Element	Convention	Example
Classes	PascalCase	Employee, Order
Methods	PascalCase (or snake_case in Python)	CalculateTotal()
Properties	PascalCase	FirstName, Amount
Fields	camelCase or _camelCase	totalPrice, _count
Local variables	camelCase	userId, balance
Constants	PascalCase	MaxLimit, TaxRate
Interfaces	Prefix with ‘I’	IRepository
Enums	PascalCase	OrderStatus

6. Deep Nesting
Nested code blocks make logic harder to follow and maintain.
Deep Nesting Example:

if (list != null)
{
    foreach (var item in list)
    {
        if (item > 0)
        {
            if (item % 2 == 0)
            {
                Console.WriteLine(item);
            }
        }
    }
}

Refactored Using Guard Clauses:

if (list == null) return;

foreach (var item in list)
{
    if (item <= 0 || item % 2 != 0) continue;

    Console.WriteLine(item);
}

Further Refactor:
Move logic to a helper method:


foreach (var item in list)
{
    ProcessItem(item);
}

void ProcessItem(int item)
{
    if (item <= 0 || item % 2 != 0) return;
    Console.WriteLine(item);
} 

Replacing Conditional Logic with Strategy Pattern
Before (using if-else):

if (type == "Regular") return amount * 0.05;
else if (type == "Premium") return amount * 0.1;
else return 0;

Refactored using Strategy Pattern:
Create an interface:

csharp

public interface IDiscountStrategy
{
    double GetDiscount(double amount);
}

Implement different strategies:

csharp

public class RegularDiscount : IDiscountStrategy
{
    public double GetDiscount(double amount) => amount * 0.05;
}

public class PremiumDiscount : IDiscountStrategy
{
    public double GetDiscount(double amount) => amount * 0.10;
}

Use a factory or context to apply the strategy:

csharp

public class DiscountContext
{
    private readonly IDiscountStrategy _strategy;

    public DiscountContext(IDiscountStrategy strategy)
    {
        _strategy = strategy;
    }

    public double ApplyDiscount(double amount) => _strategy.GetDiscount(amount);
}