Convenções de nomenclatura em Java

O compilador Java não se importa com o que você nomeia as coisas, desde que as regras de identificadores sejam seguidas. A comunidade, porém, segue um conjunto rígido de convenções de nomenclatura que permanecem as mesmas desde o lançamento da linguagem. Segui-las faz com que seu código pareça nativo para qualquer pessoa que o leia, e muitas inspeções de IDE e regras de lint as pressupõem.

As convenções em resumo

Exemplos em código:

package com.example.billing;

public class InvoicePrinter {
    public static final int MAX_LINE_WIDTH = 80;

    private int lineCount;

    public void print(Invoice invoice) {
        for (LineItem item : invoice.getItems()) {
            renderLine(item);
        }
    }

    private void renderLine(LineItem item) { ... }
}

Classes, interfaces, enums, records

Use UpperCamelCase — capitalize a primeira letra de cada palavra, sem separadores:

• Customer, OrderRepository, HttpClient, XmlParser (siglas geralmente são tratadas como palavras: Http, Xml)

Tratar acrônimos como palavras mantém os limites legíveis: parseHttpUrl é mais fácil de ler do que parseHTTPURL, onde três sequências de maiúsculas se confundem. O próprio JDK é inconsistente aqui (HttpURLConnection antecede a convenção), então, na dúvida, siga o código ao redor.

Nomes de classes devem ser substantivos: Order, Connection, BankAccount.

Interfaces também usam UpperCamelCase. Dois padrões comuns de nomenclatura:

• Adjetivo terminado em -able: Comparable, Runnable, Serializable.
• Substantivo que nomeia um papel: List, Repository, Connection.

Evite o prefixo I da notação húngara antiga (ICustomer) — o código Java não faz isso. A mesma regra UpperCamelCase se aplica a enums e interfaces.

Métodos e variáveis

Use lowerCamelCase: primeira palavra em minúsculas, cada palavra subsequente com inicial maiúscula:

• calculateTotal, parseDate, getUserName, index, lineCount.

Nomes de métodos devem ser verbos ou locuções verbais:

• save, findById, validate, parseJson.

Prefixos verbais comuns:

• get / set — acessor e mutador (também chamados getter e setter).
• is / has / can — retornam um boolean: isEmpty, hasNext, canExecute.
• to — retornam uma forma convertida: toString, toUpperCase.
• from — método de fábrica: LocalDate.from(temporal).

Nomes de variáveis devem descrever o que o valor é, não como ele é usado. Prefira customer a obj, lineCount a n. Nomes de uma letra são aceitáveis para índices de laço (i, j) e locais de curta duração onde o tipo é óbvio (var p = new Point(...)).

Constantes

Uma constante é um campo static final. Use UPPER_SNAKE_CASE:

public static final int MAX_RETRIES = 3;
public static final String DEFAULT_GREETING = "Hello";
public static final Duration TIMEOUT = Duration.ofSeconds(30);

Variáveis final locais (associações únicas dentro de um método) NÃO são consideradas constantes no mesmo sentido — mantenha-as em lowerCamelCase:

public void process(Order o) {
    final int maxAttempts = 3;   // not MAX_ATTEMPTS
    ...
}

Pacotes

Nomes de pacotes são todos em minúsculas, separados por pontos. A convenção da comunidade é usar um domínio invertido que você controla:

• com.google.guava
• org.apache.commons.lang3
• com.example.billing.invoices

Evite underscores ou letras maiúsculas em nomes de pacotes — são considerados não idiomáticos.

Parâmetros de tipo

Parâmetros de tipo genérico geralmente são letras maiúsculas únicas. As convenções de facto:

• T — tipo (geral)
• E — elemento (em uma coleção)
• K — chave
• V — valor
• R — tipo de retorno
• S, U — segundo, terceiro parâmetro de tipo quando há mais de um

public interface List<E> { ... }
public interface Map<K, V> { ... }
public interface Function<T, R> { ... }

Para APIs complexas onde uma única letra não é clara, use um nome descritivo em UpperCamelCase terminado em T: RequestT, ResponseT. Isso é raro.

Booleanos

Nomes de variáveis e métodos boolean geralmente são formulados como predicados:

• isActive, hasNext, canExecute, shouldRetry.

Evite nomes negativos como isNotEmpty — eles ficam difíceis de ler quando combinados com !.

Más práticas de nomenclatura a evitar

• Nomes de uma letra fora de um laço restrito: int s = 100 não diz nada.
• Notação húngara: strName, iCount — Java é tipado estaticamente, a IDE mostra o tipo.
• Sufixos numéricos: total1, total2, processData2. Se você precisa de dois, encontre uma distinção real.
• Constantes no estilo enum em maiúsculas para tudo que é final: apenas constantes verdadeiras em nível de módulo recebem o tratamento UPPER_SNAKE.
• Capitalização inconsistente entre membros relacionados: se um método é getUserId, o vizinho não deveria ser get_email.

Uma demonstração

Cada nome aqui segue a convenção padrão: classe em UpperCamelCase, constante em UPPER_SNAKE_CASE, variáveis em lowerCamelCase, boolean nomeado como predicado.

O que vem a seguir

Tipos de dados em Java apresenta os tipos primitivos e de referência do Java — os blocos de construção de que cada variável é feita.

Prática