How to write a Clean Code

Caique Santos — Wed, 08 Apr 2026 23:58:14 +0000

Introduction

Clean Code is a concept popularized by the book of the same name, written by Robert C. Martin. The main ideia of the book is that a clean code can be read and enhanced by a developer other than its original author. The pillars of this concept are the following below:

Clear naming:

Instead of using:
var x = GetData();
Prefer:
var userEmails = GetUserEmails();

Functions responsability

A function should be as short as possible, and do only one thing.
Avoid:
ProcessUserDataAndSendEmai(user);
Instead, prefer:
ProcessUserData(user);
SendEmail(user);

Low coupling

Avoid tight coupling by instantiating dependencies directly:
private EmailService _emailService = new EmailService();
Prefer depending on abstractions:
private IEmailService _emailService;

Self-explanatory code

Comments can be helpful, but code should be clear on its own.
Avoid:
// increase processed items count count++;
Prefer:
processedItemsCount++;

Consistency

You should stick to a standard. Avoid mixing different naming conventions:
var itensCount= 5; var discount_amount= 0.2;
Use the same pattern:
var itensCount= 5; var discountAmount= 0.2;

Overview

Good code is code that anyone can understand quickly.
You should be able to come back to it years later and still understand it.
It should also be easy to change.

SOLID Principles you won't forget again

Caique Santos — Wed, 08 Apr 2026 23:24:56 +0000

Introduction

SOLID is a set of design principles for writing clean, maintainable, and scalable code. It stands for:

S- Single Responsibility Principle (SRP)

A class or function should have only one responsibility. In the bad example below, the CreateUser function should not handle email-related logic.

Bad example:

public class UserService {
    public void CreateUser(string email) {

        var user = new User(email); 
        _repository.Save(user);

        var smtpClient = new SmtpClient("smtp.company.com"); 
        var message = new MailMessage(                       
            "no-reply@myapp.com", email,"Welcome!",          
            "Your account was created successfully."         
        );                                                   
       smtpClient.Send(message);                           
    }
}

Good example:

public class UserService{
     public void CreateUser(string email) {

        var user = new User(email); 
        _repository.Save(user);

        _emailService.SendWelcome(email);
    }
}

O — Open/Closed Principle (OCP)

Code should be open for extension but closed for modification. This means you should be able to add new behavior without changing existing code. In the bad example below, whenever a new discount is added, you edit the function.

Bad example:

public class DiscountService {
    public double Calculate(string type) {
        if (type == "VIP") return 0.2;            
        if (type == "Regular") return 0.1;
        if (type == "Employee") return 0.3;

        return 0;
    }
}

Good example:

public interface IDiscount {
    double Calculate();
}
public class VipDiscount : IDiscount{ 
    public double Calculate() => 0.2;
}
public class RegularDiscount : IDiscount {
    public double Calculate() => 0.1;
}

public class DiscountService {
    public double Calculate(IDiscount discount) {
        return discount.Calculate();
    }
}

L- Liskov Substitution Principle (LSP)

Subtypes must be replaceable for their base types without breaking the system. This means you should be able to use a subclass anywhere the base class is expected, without causing issues. In the bad example below, the subclass breaks the expected behavior by throwing an exception.

Bad example:

public class Bird {
    public virtual void Fly() { }
}

public class Penguin : Bird {
    public override void Fly() {
        throw new Exception("Penguins can't fly");
    }
}

Bird bird = new Penguin();
bird.Fly();                      // throws exception

Good example:

public abstract class Bird { }

public interface IFlyingBird {
    void Fly();
}

public class Eagle : Bird, IFlyingBird {
    public void Fly() { }
}

public class Penguin : Bird { }

I- Interface Segregation Principle (ISP)

Clients should not depend on methods they do not use. The example below looks like the one from LSP, but the difference here it's about dependency minimization, and the other one is about behavioral contracts.

Bad example:

public interface IWorker
{
    void Work();
    void Eat();
}

public class Robot : IWorker
{
    public void Work() { }

    public void Eat()
    {
        //forced to implement this method even though it doesn't use it
    }
}

Good example:

public interface IWorkable {
    void Work();
}

public interface IEatable {
    void Eat();
}

public class Human : IWorkable, IEatable {
    public void Work() { }
    public void Eat() { }
}

public class Robot : IWorkable {
    public void Work() { }
}

D- Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules. Both should depend on abstractions. In other words, don’t depend on concrete implementations — depend on abstractions.

Bad example:

public class UserService
{
    private EmailService _emailService = new EmailService();

    public void CreateUser(string email)
    {
        // logic
        _emailService.Send(email);
    }
}

Good example:

public interface IEmailService{
    void Send(string email);
}
public class EmailService : IEmailService{
    public void Send(string email) { }
}
public class UserService{
    private readonly IEmailService _emailService;

    public UserService(IEmailService emailService) {
        _emailService = emailService;
    }

    public void CreateUser(string email) {
        _emailService.Send(email);
    }
}

DEV Community: Caique Santos

How to write a Clean Code

Introduction

Clear naming:

Functions responsability

Low coupling

Self-explanatory code

Consistency

Overview

SOLID Principles you won't forget again

Introduction

S- Single Responsibility Principle (SRP)

O — Open/Closed Principle (OCP)

L- Liskov Substitution Principle (LSP)

I- Interface Segregation Principle (ISP)

D- Dependency Inversion Principle (DIP)