Convenciones de codificación en Java

Las convenciones de codificación son las reglas compartidas que hacen que el código Java parezca escrito por una sola persona, incluso cuando un equipo de cincuenta lo modifica. Abarcan nombres, indentación, colocación de llaves, longitud de línea y disposición de archivos — aspectos que al compilador no le importan en absoluto, pero que determinan si el próximo lector (a menudo tú, meses después) puede recorrer un método en segundos o tiene que descifrarlo. Java tiene convenciones inusualmente sólidas porque se publicaron temprano, en las Code Conventions for the Java Programming Language originales de Sun, y han permanecido notablemente estables desde entonces.

Por qué las convenciones importan más que el compilador

La JVM ejecuta int X=1;if(X>0){return"a";} exactamente igual de rápido que el código bien formateado. Las convenciones existen para los humanos: el código se lee con mucha más frecuencia de lo que se escribe, y un estilo coherente elimina una capa de fricción en cada lectura. Un segundo beneficio práctico es la higiene del diff — cuando todos aplican el mismo formato, un diff de control de versiones muestra cambios reales de lógica en lugar de ruido de reformateo. La mayoría de los equipos aplican un único estilo automáticamente (con un formateador) precisamente para que el estilo deje de ser un tema de discusión en las revisiones de código.

Nombres: la convención que usas en cada línea

Los nombres transmiten casi todo el significado de un programa, y las reglas de nomenclatura de Java son casi universales en todo el ecosistema:

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;
  }
}

Evita las abreviaciones que no son estándar en la industria (accelerationTime, no accTime), y que la longitud del nombre corresponda a su ámbito — un índice de bucle puede ser i, pero un campo que existe durante toda la vida de un objeto merece una palabra completa.

Formato: llaves, indentación y longitud de línea

Java usa de manera abrumadora el estilo de llaves K&R: la llave de apertura va en la misma línea que la declaración, y la llave de cierre queda alineada bajo el inicio de esa sentencia. La indentación estándar es de 4 espacios (nunca tabulaciones en las guías oficiales), y las líneas se mantienen en un ancho razonable — el límite clásico era de 80 columnas; guías modernas como la de Google usan 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();
}

Algunas reglas que evitan los comentarios de revisión más comunes: una sentencia por línea, una línea en blanco entre métodos, un espacio después de las palabras clave (if (, no if(), y sin espacios en blanco al final de la línea.

Guías de estilo reconocidas

Rara vez se inventan convenciones desde cero — se adopta una guía publicada y se deja que una herramienta la aplique:

La guía específica importa menos que elegir una y aplicarla de forma coherente. Herramientas como Checkstyle (verifica el estilo y falla la compilación ante violaciones), Spotless y google-java-format (formatean automáticamente al guardar o al hacer commit), y los formateadores de IDE eliminan por completo el factor humano.

Un ejemplo detallado: reglas de convención en código funcional

El compilador es ciego al estilo, por lo que un programa ejecutable no puede "probar" el formato directamente. Lo que sí puede hacer es ejercitar las reglas de nomenclatura y estructura en código real — constantes, métodos en camelCase, llaves K&R, variables de tipo interfaz — e imprimir resultados que demuestran que cada pieza cumple su función.

Lo que se puede observar en la ejecución:

• MAX_RETRIES constant = 3 muestra la constante UPPER_SNAKE_CASE en uso. Declarar valores como private static final y nombrarlos en upper-snake-case indica "esto nunca cambia" a cualquier lector de un vistazo — la convención codifica la intención que el compilador no puede.
• grossPrice(100.00) = 120.00 proviene de un método cuyo nombre verbal en camelCase se lee como una instrucción. El parámetro netPrice y el uso de TAX_RATE en el cuerpo hacen que el cálculo se explique solo; se entiende sin necesidad de un comentario.
• grades = [A, B, C] lo produce classify, escrito en estilo de llaves K&R con llaves explícitas en cada rama — incluso en las que tienen un solo return. Esas llaves son las que evitan que una edición posterior cree accidentalmente una sentencia colgante.
• total name length = 10 proviene de un bucle for mejorado sobre una List<String> declarada con el tipo interfaz a la izquierda, no ArrayList. Programar contra la interfaz es la convención que mantiene el resto del código libre para intercambiar implementaciones.
• totalLength is even muestra un boolean nombrado como pregunta (isEven) que alimenta un ternario corto y de propósito único. Convenciones como estas son invisibles cuando se siguen y llamativas cuando se rompen — que es exactamente por qué los equipos las automatizan.

Qué cubre el resto de esta parte

Las convenciones son la capa superficial; los capítulos siguientes pasan de cómo se ve el código a cómo está estructurado:

• Clean Code — prácticas que mantienen los métodos pequeños y legibles más allá del formato.
• Naming Best Practices — elegir nombres que se explican por sí mismos.
• Immutability Best Practices — diseñar objetos que no pueden cambiar después de su construcción.
• SOLID Principles — las reglas de diseño que definen cómo las clases dependen unas de otras.

Práctica