Código limpo em Java: regras que salvarão seu projeto

Por que código limpo não é luxo, mas necessidade

Imagine que você entra em um projeto de outra pessoa. As classes se chamam Class1, Manager, UltraProcessor. Os métodos fazem tudo de uma vez: consulta ao banco, renderização de HTML e envio de email. E as variáveis — x, y, temp. Familiar? Se sim, você sabe como esse tipo de código rapidamente transforma a vida do desenvolvedor em um inferno.

Código limpo em Java não é sobre pedantismo. É sobre respeito aos colegas, ao seu eu futuro e ao negócio. Código sujo retarda o desenvolvimento em 2 a 3 vezes, torna os bugs indetectáveis e a refatoração impossível. Neste artigo, vamos abordar regras específicas que ajudarão você a escrever código que dá gosto ler e manter.

Regra nº 1: Nomenclatura — 50% do sucesso

Robert Martin (Tio Bob) no livro "Código Limpo" afirma: um bom nome substitui um comentário. Desenvolvedores Java frequentemente pecam com nomes abstratos. Vamos corrigir isso.

Variáveis: diga o que você armazena

Ruim:

int d; // tempo decorrido em dias

Bom:

int elapsedTimeInDays;

Ruim:

List<String> list = new ArrayList<>();

Bom:

List<String> customerNames = new ArrayList<>();

Métodos: verbo + contexto

O método deve responder à pergunta "o que faz?". Evite palavras genéricas como process, handle, doStuff.

Ruim:

public void process(int id) {\n    // 50 linhas de código: validação, cálculo, envio de email\n}

Bom:

public void sendEmailConfirmation(int orderId) {\n    // apenas a lógica de envio de email\n}

Classes: substantivos sem sufixos parasitas

Evite Manager, Processor, Util, a menos que seja justificado. A classe deve refletir a entidade.

Ruim: DataProcessor, UserManager

Bom: UserRepository, InvoiceCalculator, EmailSender

Regra nº 2: Métodos — curtos e com uma única tarefa

Regra de ouro: um método — uma responsabilidade. Se o método tiver mais de 15-20 linhas, provavelmente precisa ser dividido. Isso melhora a legibilidade do código Java e simplifica os testes.

Exemplo de refatoração

Antes:

public boolean isValidOrder(Order order) {\n    if (order == null) return false;\n    if (order.getItems().isEmpty()) return false;\n    double total = 0;\n    for (Item item : order.getItems()) {\n        total += item.getPrice() * item.getQuantity();\n    }\n    if (total > 10000) {\n        // verificação de limite de crédito\n        User user = userRepository.findById(order.getUserId());\n        return user.getCreditLimit() >= total;\n    }\n    return true;\n}

Depois:

public boolean isValidOrder(Order order) {\n    if (isOrderNullOrEmpty(order)) return false;\n    double total = calculateTotal(order);\n    if (isHighValueOrder(total)) {\n        return hasSufficientCredit(order.getUserId(), total);\n    }\n    return true;\n}\n\nprivate boolean isOrderNullOrEmpty(Order order) {\n    return order == null || order.getItems().isEmpty();\n}\n\nprivate double calculateTotal(Order order) {\n    return order.getItems().stream()\n            .mapToDouble(item -> item.getPrice() * item.getQuantity())\n            .sum();\n}\n\nprivate boolean isHighValueOrder(double total) {\n    return total > 10000;\n}\n\nprivate boolean hasSufficientCredit(int userId, double total) {\n    User user = userRepository.findById(userId);\n    return user.getCreditLimit() >= total;\n}

Regra nº 3: Comentários — apenas quando não há outro jeito

Um comentário frequentemente é uma desculpa para código ruim. Em vez de escrever "// obtém