Convenções de Código Java

Convenções de código são as regras compartilhadas que fazem o código Java parecer escrito por uma única pessoa, mesmo quando uma equipe de cinquenta pessoas o modifica. Elas abrangem nomenclatura, indentação, posicionamento de chaves, comprimento de linha e organização de arquivos — nada disso importa para o compilador, mas tudo isso determina se o próximo leitor (muitas vezes você mesmo, meses depois) consegue examinar um método em segundos ou precisa decifrá-lo. Java tem convenções excepcionalmente fortes porque foram publicadas cedo, nas Code Conventions for the Java Programming Language originais da Sun, e têm sido notavelmente estáveis desde então.

Por que as convenções importam mais do que o compilador

A JVM executa int X=1;if(X>0){return"a";} exatamente na mesma velocidade que código bem formatado. As convenções existem para humanos: o código é lido com muito mais frequência do que é escrito, e um estilo consistente elimina uma camada de atrito a cada leitura. Um segundo benefício prático é a higiene de diff — quando todos formatam da mesma forma, um diff de controle de versão mostra alterações reais de lógica em vez de ruído de reformatação. A maioria das equipes impõe um único estilo automaticamente (com um formatador) precisamente para que o estilo deixe de ser uma discussão em revisões de código.

Nomenclatura: a convenção que você usa em cada linha

Os nomes carregam quase todo o significado de um programa, e as regras de nomenclatura do Java são praticamente universais em todo o ecossistema:

public class InvoiceCalculator {        // PascalCase class
  private static final int MAX_ITEMS = 100;  // UPPER_SNAKE_CASE constant
  private int lineCount;                 // camelCase field

  public boolean isOverLimit() {         // camelCase verb, boolean reads as a question
    return lineCount > MAX_ITEMS;
  }
}

Evite abreviações que não sejam padrões do setor (accelerationTime, não accTime), e deixe o tamanho do nome corresponder ao seu escopo — um índice de loop pode ser i, mas um campo que vive durante toda a existência de um objeto merece uma palavra completa.

Formatação: chaves, indentação e comprimento de linha

Java usa predominantemente o estilo de chaves K&R: a chave de abertura fica na mesma linha da declaração, e a chave de fechamento se alinha com o início dessa instrução. A indentação padrão é de 4 espaços (nunca tabulações nos guias oficiais), e as linhas são mantidas em uma largura razoável — o limite clássico era de 80 colunas; guias modernos como o do Google usam 100.

// K&R: opening brace on the same line, always use braces
if (user.isActive()) {
  sendWelcome(user);
} else {
  queueReminder(user);
}

// Even a one-line body gets braces — it prevents the classic "dangling statement" bug
for (Order order : orders) {
  total += order.amount();
}

Algumas regras que evitam os comentários de revisão mais comuns: uma instrução por linha, uma linha em branco entre métodos, um espaço após palavras-chave (if (, não if(), e sem espaços em branco no final da linha.

Guias de estilo reconhecidos

Raramente se inventam convenções do zero — adota-se um guia publicado e deixa-se uma ferramenta aplicá-lo:

O guia específico importa menos do que escolher um e aplicá-lo de forma consistente. Ferramentas como Checkstyle (verifica o estilo e falha o build em caso de violações), Spotless e google-java-format (formatação automática ao salvar ou ao fazer commit) e formatadores de IDE removem completamente o elemento humano.

Um exemplo completo: regras de convenção em código funcional

O compilador é cego ao estilo, então um programa executável não pode "testar" a formatação diretamente. O que ele pode fazer é exercitar as regras de nomenclatura e estrutura em código real — constantes, métodos em camelCase, chaves K&R, variáveis tipadas por interface — e imprimir resultados que provam que cada parte está funcionando.

O que aprender com a execução:

• MAX_RETRIES constant = 3 mostra a constante UPPER_SNAKE_CASE em uso. Declarar valores como private static final e nomeá-los em upper-snake-case sinaliza "isso nunca muda" para cada leitor à primeira vista — a convenção codifica a intenção que o compilador não consegue.
• grossPrice(100.00) = 120.00 veio de um método cujo nome verbal em camelCase lê-se como uma instrução. O parâmetro netPrice e o uso de TAX_RATE no corpo tornam o cálculo autodocumentado; você o entende sem um comentário.
• grades = [A, B, C] é produzido por classify, escrito no estilo de chaves K&R com chaves explícitas em cada ramo — até mesmo os ramos de retorno único. Essas chaves são o que impede que uma edição posterior crie acidentalmente uma instrução suspensa.
• total name length = 10 vem de um for-loop aprimorado sobre um List<String> declarado com o tipo de interface à esquerda, não ArrayList. Codificar para a interface é a convenção que mantém o restante do código livre para trocar implementações.
• totalLength is even mostra um boolean nomeado como uma pergunta (isEven) alimentando um ternário curto e de propósito único. Convenções como essas são invisíveis quando seguidas e perturbadoras quando violadas — razão pela qual as equipes as automatizam.

O que o restante desta parte abrange

As convenções são a camada superficial; os capítulos a seguir passam de como o código parece para como ele é estruturado:

• Clean Code — práticas que mantêm os métodos pequenos e legíveis além da formatação.
• Naming Best Practices — escolher nomes que se explicam sozinhos.
• Immutability Best Practices — projetar objetos que não podem ser alterados após a construção.
• SOLID Principles — as regras de design que moldam como as classes dependem umas das outras.

Prática