Convenciones de codificación de Java

Las convenciones de codificación son las reglas compartidas que hacen que el código Java parezca escrito por una sola persona, aunque lo toque un equipo de cincuenta. Cubren el nombrado, la indentación, la colocación de llaves, la longitud de línea y la disposición de los archivos — nada de lo cual le importa al compilador, pero todo lo cual decide si el próximo lector (a menudo usted, meses después) puede recorrer un método en segundos o tiene que descifrarlo. Java tiene convenciones inusualmente fuertes porque se publicaron pronto, 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 un código bien formateado. Las convenciones existen para las personas: el código se lee mucho más a menudo de lo que se escribe, y un estilo coherente elimina una capa de fricción en cada lectura. Una segunda recompensa, práctica, es la higiene de los diffs — cuando todos formatean igual, un diff de control de versiones muestra cambios reales de lógica en lugar de ruido de reformateo. La mayoría de los equipos imponen un único estilo automáticamente (con un formateador) precisamente para que el estilo deje de ser un tema de discusión en la revisión de código.

El nombrado: la convención que usa en cada línea

Los nombres llevan casi todo el significado de un programa, y las reglas de nombrado 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;
  }
}

Evite las abreviaturas que no sean estándar de la industria (accelerationTime, no accTime), y deje que la longitud de un nombre se corresponda con su ámbito — un índice de bucle puede ser i, pero un campo que vive durante toda la vida de un objeto merece una palabra completa.

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

Java usa abrumadoramente 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 se alinea bajo el inicio de esa instrucción. La indentación estándar es de 4 espacios (nunca tabuladores en las guías oficiales), y las líneas se mantienen en un ancho razonable — el límite clásico era de 80 columnas; las 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();
}

Unas pocas reglas que evitan los comentarios de revisión más comunes: una instrucción 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 al final de la línea.

Guías de estilo reconocidas

Rara vez inventa convenciones desde cero — adopta una guía publicada y deja que una herramienta la haga cumplir:

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

Un ejemplo resuelto: las reglas de convención en código en funcionamiento

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

Qué llevarse de 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 le señala a cada lector de un vistazo «esto nunca cambia» — la convención codifica una intención que el compilador no puede expresar.
• grossPrice(100.00) = 120.00 provino 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 autodocumente; lo entiende sin 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 los brazos de un solo return. Esas llaves son las que impiden que una edición posterior cree por accidente una instrucción colgante.
• total name length = 10 proviene de un bucle for mejorado sobre una List<String> declarada con el tipo de interfaz a la izquierda, no ArrayList. Programar hacia la interfaz es la convención que mantiene al resto del código libre para intercambiar implementaciones.
• totalLength is even muestra un booleano nombrado como una pregunta (isEven) que alimenta un ternario corto y de propósito único. Convenciones como estas son invisibles cuando se siguen y chocantes cuando se rompen — que es exactamente por lo que los equipos las automatizan.

Qué cubre el resto de esta parte

Prácticas de código limpio, nombrado eficaz, inmutabilidad, patrones de manejo de errores y los principios de diseño (SOLID, DRY) que se construyen sobre esta base. Las convenciones son la capa superficial; los capítulos siguientes pasan de cómo luce el código a cómo está estructurado.

Practice