Convenciones de nomenclatura en Java

Al compilador de Java no le importa cómo nombres las cosas, siempre que se sigan las reglas de identificadores. Sin embargo, la comunidad sigue un conjunto estricto de convenciones de nomenclatura que se han mantenido iguales desde que se lanzó el lenguaje. Respetarlas hace que tu código parezca nativo para cualquiera que lo lea, y muchas inspecciones de IDE y reglas de lint las asumen.

Las convenciones de un vistazo

Ejemplos en 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) { ... }
}

Clases, interfaces, enums, records

Usa UpperCamelCase — escribe con mayúscula la primera letra de cada palabra, sin separadores:

• Customer, OrderRepository, HttpClient, XmlParser (los acrónimos normalmente se tratan como palabras: Http, Xml)

Tratar los acrónimos como palabras mantiene los límites legibles: parseHttpUrl es más fácil de leer que parseHTTPURL, donde tres series de mayúsculas se confunden. El propio JDK es inconsistente aquí (HttpURLConnection es anterior a la convención), así que cuando tengas dudas, sigue el código que te rodea.

Los nombres de clases deben ser sustantivos: Order, Connection, BankAccount.

Las interfaces también usan UpperCamelCase. Dos patrones de nomenclatura comunes:

• Adjetivo terminado en -able: Comparable, Runnable, Serializable.
• Sustantivo que nombra un rol: List, Repository, Connection.

Evita el prefijo I del antiguo estilo húngaro (ICustomer) — el código Java no hace eso. La misma regla UpperCamelCase aplica a los enums e interfaces.

Métodos y variables

Usa lowerCamelCase: primera palabra en minúsculas, cada palabra siguiente en mayúscula:

• calculateTotal, parseDate, getUserName, index, lineCount.

Los nombres de métodos deben ser verbos o frases verbales:

• save, findById, validate, parseJson.

Prefijos verbales comunes:

• get / set — acceso y modificación (también llamados getter y setter).
• is / has / can — devuelven un boolean: isEmpty, hasNext, canExecute.
• to — devuelven una forma convertida: toString, toUpperCase.
• from — método de fábrica: LocalDate.from(temporal).

Los nombres de variables deben describir qué es el valor, no cómo se usa. Prefiere customer sobre obj, lineCount sobre n. Los nombres de una sola letra están bien para índices de bucle (i, j) y variables locales de vida corta donde el tipo es obvio (var p = new Point(...)).

Constantes

Una constante es un campo static final. Usa 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);

Las variables final locales (enlaces de un solo uso dentro de un método) NO se consideran constantes en el mismo sentido — mantenlas en lowerCamelCase:

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

Paquetes

Los nombres de paquetes van todos en minúsculas, separados por puntos. La convención de la comunidad es usar un dominio invertido que controles:

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

Evita guiones bajos o letras mayúsculas en los nombres de paquetes — se consideran no idiomáticos.

Parámetros de tipo

Los parámetros de tipo genérico suelen ser letras mayúsculas únicas. Las convenciones de facto:

• T — tipo (general)
• E — elemento (en una colección)
• K — clave
• V — valor
• R — tipo de retorno
• S, U — segundo y tercer parámetro de tipo cuando hay más de uno

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

Para APIs complejas donde una sola letra no es clara, usa un nombre descriptivo en UpperCamelCase que termine en T: RequestT, ResponseT. Esto es poco frecuente.

Booleanos

Los nombres de variables y métodos boolean se formulan normalmente como predicados:

• isActive, hasNext, canExecute, shouldRetry.

Evita nombres negativos como isNotEmpty — se leen mal cuando se combinan con !.

Malos nombres que evitar

• Nombres de una letra fuera de un bucle corto: int s = 100 no dice nada.
• Notación húngara: strName, iCount — Java es de tipado estático, el IDE muestra el tipo.
• Sufijos numéricos: total1, total2, processData2. Si necesitas dos, encuentra una distinción real.
• Constantes en UPPER_SNAKE para todo lo que sea final: solo las constantes de nivel de módulo verdaderas reciben el tratamiento UPPER_SNAKE.
• Casing inconsistente entre elementos relacionados: si un método es getUserId, el vecino no debería ser get_email.

Una demostración

Cada nombre aquí sigue la convención estándar: clase en UpperCamelCase, constante en UPPER_SNAKE_CASE, variables en lowerCamelCase, boolean nombrado como predicado.

Qué sigue

Tipos de datos en Java presenta los tipos primitivos y de referencia de Java — los bloques de construcción de los que está hecha cada variable.

Práctica