Clean Code é uma filosofia de desenvolvimento de software popularizada pelo livro Clean Code, de Robert C. Martin.

A ideia central é simples:

Código é lido muito mais vezes do que é escrito. Portanto, ele deve ser escrito para humanos primeiro e computadores depois.

Um código "limpo" é aquele que outro desenvolvedor (ou você mesmo daqui a 6 meses) consegue entender rapidamente sem precisar virar arqueólogo.

Exemplo simples

Código ruim:

func p(a []User) []User {
    var r []User
    for _, x := range a {
        if x.Age >= 18 && x.Active == true {
            r = append(r, x)
        }
    }
    return r
}

Código limpo:

func FilterActiveAdults(users []User) []User {
    var adults []User

    for _, user := range users {
        if user.IsActive && user.Age >= 18 {
            adults = append(adults, user)
        }
    }

    return adults
}

O computador vê os dois como praticamente a mesma coisa.

O humano não.

Os princípios mais importantes

1. Nomes significativos

Ruim:

var d int

Bom:

var retryCount int

Ruim:

func calc(a, b float64) float64

Bom:

func CalculateDiscount(price, percentage float64) float64

2. Funções pequenas

Ruim:

func RegisterUser() {
    // valida
    // cria hash
    // salva banco
    // envia email
    // gera log
    // cria sessão
}

Bom:

func RegisterUser() {
    validateUser()
    hashPassword()
    saveUser()
    sendWelcomeEmail()
}

Cada função faz uma coisa.

3. Uma responsabilidade por função

Princípio conhecido como Single Responsibility Principle (SRP).

Ruim:

func ProcessOrder() {
    calculatePrice()
    saveDatabase()
    sendEmail()
    printPdf()
}

Bom:

func ProcessOrder() {
    total := calculatePrice()
    persistOrder(total)
    notifyCustomer()
}

4. Evitar comentários desnecessários

Muita gente acha que Clean Code = mais comentários.

É o contrário.

Ruim:

// Incrementa o contador em 1
counter++

Bom:

counter++

O comentário não agrega nada.

Comentários devem explicar:

Não o óbvio.

5. Evitar duplicação

Ruim:

func CreateUser() {
    db.Connect()
}

func CreatePost() {
    db.Connect()
}

Bom:

func getDB() *DB {
    return db.Connect()
}

Duplicação gera bugs.

Quando você corrige um lugar e esquece outro.

6. Menos níveis de indentação

Ruim:

if user != nil {
    if user.Active {
        if user.IsAdmin {
            ...
        }
    }
}

Bom:

if user == nil {
    return
}

if !user.Active {
    return
}

if !user.IsAdmin {
    return
}

...

Chamado de guard clauses.

Muito comum em Go.

7. Evitar funções gigantes

Se você precisa dar scroll 5 vezes para entender uma função:

func GenerateReport() {
    // 500 linhas
}

Provavelmente ela faz coisas demais.

O problema do Clean Code

Hoje existe uma reação contra algumas ideias do livro.

Muitos desenvolvedores experientes consideram que algumas recomendações foram levadas ao extremo.

Exemplo:

func getUser() {}
func validateUser() {}
func formatUser() {}
func saveUser() {}

Às vezes isso gera:

Você passa mais tempo pulando entre arquivos do que lendo lógica.

A visão moderna

Hoje a maioria dos times segue algo mais próximo de:

Código deve ser simples de entender, mesmo que não seja perfeitamente "Clean Code".

Ou seja:

✅ bons nomes

✅ pouca duplicação

✅ responsabilidades claras

✅ funções razoavelmente pequenas

✅ arquitetura simples

Mas sem transformar tudo em abstrações.

Regra prática

Uma boa definição moderna de Clean Code é:

Um desenvolvedor novo no projeto consegue entender o que o código faz em poucos minutos sem precisar perguntar para ninguém.

Se a resposta for "sim", seu código provavelmente já está limpo o suficiente.

O maior erro que vejo em projetos Go, Rust e TypeScript hoje não é falta de Clean Code. É o excesso dele: abstrações, interfaces e camadas criadas "para ficar bonito" que acabam tornando o sistema mais difícil de entender do que uma implementação direta e simples.