1. Introducción
En programación, el estilo no va de moda, sino de supervivencia. Java es un lenguaje en el que escriben equipos enormes y, si cada cual escribe «como está acostumbrado», el proyecto se convertirá rápidamente en un conjunto de piezas inconexas en el que solo podrá orientarse su autor (y no siempre).
El estilo de código es un conjunto de reglas que hacen que el código sea igualmente legible para todos. Es como las señales de tráfico: si las ignoras, la circulación se convierte en caos.
¿Por qué es importante?
- Legibilidad: el código se lee más de lo que se escribe. Un mal estilo es como la mala letra de un médico: nadie entiende lo que pone.
- Mantenibilidad: si el código está escrito siguiendo reglas, es más fácil de cambiar y es menos probable romper algo por accidente.
- Trabajo en equipo: en un equipo, todos deben entenderse sin preguntas innecesarias.
- Herramientas: los autoformateadores y los analizadores de código funcionan mejor si el estilo es uniforme.
2. Errores principales de estilo de código (y cómo evitarlos)
Incumplimiento de sangrías y llaves
Error:
Un código sin sangrías y con llaves caóticas tortura la vista y el cerebro.
if(x>0){
System.out.println("x es positivo");
}else{
System.out.println("x no es positivo");
}
Cómo debe ser:
if (x > 0) {
System.out.println("x es positivo");
} else {
System.out.println("x no es positivo");
}
Comentario:
Usa cuatro espacios por cada nivel de anidación (es el estándar de Java). La tabulación es el mal, salvo que todo el equipo haya acordado lo contrario.
Nombres incorrectos de variables, métodos y clases
Error:
int a = 5;
String s = "Vasya";
void f() { /* ... */ }
Cómo debe ser:
int age = 5;
String userName = "Vasya";
void printReport() { /* ... */ }
Comentario:
Los nombres deben ser significativos y reflejar la esencia de la variable o el método.
- Clases: con mayúscula inicial, CamelCase: UserAccount.
- Métodos y variables: con minúscula inicial, camelCase: calculateSalary, userList.
Métodos y clases demasiado largos
Error:
Un método de 100 líneas, una clase de 1000 líneas: un verdadero modo nightmare para el mantenimiento.
Cómo debe ser:
Cada método debe hacer una sola cosa y ser corto (idealmente, caber en la pantalla). Las clases tampoco deben crecer hasta el tamaño de «Guerra y paz».
Ejemplo:
Mal:
public void processOrder() {
// 200 líneas de código
}
Bien:
public void processOrder() {
validateOrder();
calculateTotal();
saveToDatabase();
sendEmailConfirmation();
}
Uso de «números mágicos» y cadenas
Error:
if (status == 42) {
// ...
}
Cómo debe ser:
public static final int STATUS_APPROVED = 42;
if (status == STATUS_APPROVED) {
// ...
}
Comentario:
En lugar de números y cadenas «mágicos», usa constantes (static final). En las versiones nuevas de Java también existen enum: úsalos para conjuntos limitados de valores.
Comentarios: ausencia o exceso
Error 1:
No hay comentarios en absoluto: no se entiende qué hace un código complejo.
Error 2:
Comentarios para cada acción, incluso las obvias.
// Incrementamos x en 1
x = x + 1;
// Comprobamos si x es igual a 10
if (x == 10) {
// ...
}
¡Comentarios así solo estorban! Comenta solo los puntos complejos o no evidentes. En general, un buen código debería ser comprensible sin comentarios: los comentarios deben explicar el «por qué», no el «qué».
// Tenemos en cuenta el descuento para clientes VIP
double total = calculateTotalWithDiscount();
3. Convenciones de Java: cómo escriben los profesionales
En Java hay estándares de formato oficiales y de facto. Oracle Java Code Conventions y Google Java Style Guide son los más populares.
Sangrías y llaves
La llave de apertura se coloca en la misma línea que la declaración:
public void print() {
// ...
}
La anidación: cuatro espacios.
Nomenclatura
- Clases e interfaces: CamelCase con mayúscula inicial (Person, UserAccount).
- Métodos y variables: camelCase con minúscula inicial (calculateSalary, userList).
- Constantes: MAYÚSCULAS_CON_GUIONES_BAJOS (MAX_SIZE, DEFAULT_TIMEOUT).
- Paquetes: solo minúsculas, pueden incluir puntos (com.example.project).
Espacios
Espacios alrededor de los operadores y después de las comas:
int sum = a + b;
System.out.println(name, age);
No pongas espacio después del paréntesis de apertura ni antes del de cierre:
if (x > 0) { ... }
Longitud de línea
Se recomienda no superar los 100–120 caracteres por línea. (Sí, tu monitor es enorme, pero el código se lee mejor cuando no se va al infinito horizontal.)
Orden de declaración de los miembros de la clase
Orden recomendado (según Oracle):
- Campos (primero estáticos, luego no estáticos)
- Constructores
- Métodos
Ejemplo:
public class User {
private static int userCount;
private String name;
public User(String name) {
this.name = name;
userCount++;
}
public String getName() {
return name;
}
}
4. Ejemplo: refactorización de mal estilo
He aquí un ejemplo de clase que puedes encontrar en estado salvaje:
class person{String n;int a;void p(){System.out.println(n+" "+a);}}
En alguna oficina, un desarrollador Java llora por este código.
Mejorémoslo:
public class Person {
private String name;
private int age;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
public void print() {
System.out.println(name + " " + age);
}
}
Qué cambió:
- La clase y sus miembros tienen los modificadores de acceso correctos.
- Los nombres son significativos y legibles.
- Cada miembro de la clase empieza en una nueva línea.
- Se usa un constructor para la inicialización.
- Los campos son private para respetar la encapsulación.
5. Detalles útiles
Autoformateadores
Las IDE modernas (IntelliJ IDEA, Eclipse, VS Code) pueden formatear el código automáticamente según el estándar.
Atajos de teclado:
- IntelliJ IDEA: Ctrl + Alt + L
- Eclipse: Ctrl + Shift + F
Análisis estático
Herramientas como Checkstyle, SonarLint y PMD ayudan a detectar incumplimientos de estilo y posibles errores incluso antes de ejecutar el programa.
Cómo se ve:
- Checkstyle se queja si tienes una variable llamada x en lugar de userAge.
- SonarLint te avisará si un método es demasiado largo o una clase incumple los principios SOLID.
Separación de responsabilidades y código «limpio»
- Cada clase debe responsabilizarse de una sola tarea (Single Responsibility Principle).
- No tengas miedo de crear clases y métodos adicionales: no es «inflar» el código, es pensar en el lector del futuro.
- Evita duplicar código: si ves dos fragmentos parecidos, extrae un método.
Constantes y «números mágicos»: la forma correcta
En lugar de:
double price = 100 * 0.18;
Mejor:
public static final double VAT_RATE = 0.18;
double price = 100 * VAT_RATE;
Y si a menudo manejas conjuntos fijos de valores, usa enum:
public enum Status {
NEW, IN_PROGRESS, DONE
}
6. Errores típicos en el estilo y la legibilidad del código
Error n.º 1: Ignorar las convenciones de código.
Si el equipo no tiene un estilo unificado, el código se vuelve rápidamente ilegible y difícil de mantener. Incluso si escribes en solitario, dentro de un año te lo agradecerás.
Error n.º 2: Nombres demasiado cortos/largos.
La variable a o temp es mala. La variable theCurrentUserNameThatIsUsedForAuthorizationInTheSystem tampoco es buena idea. Busca el equilibrio: userName, age, bookList.
Error n.º 3: «Números mágicos».
Insertar números y cadenas directamente en el código dificulta el mantenimiento y aumenta la probabilidad de errores.
Error n.º 4: Métodos y clases gigantes.
Cuanto más grande es un método, más difícil es probarlo y entenderlo. Divide en partes lógicas.
Error n.º 5: Mala estructura de la clase.
Campos desperdigados por cualquier sitio, métodos declarados en orden aleatorio: todo ello impide encontrar rápido lo que necesitas.
Error n.º 6: Comentarios excesivos o ausentes.
Un comentario «inicialización de variable» junto a int x = 0; no es necesario. Un comentario que explique una lógica de negocio compleja es muy necesario.
Error n.º 7: Formateo inconsistente.
En una parte del proyecto, cuatro espacios; en otra, tabulaciones; aquí las llaves en línea nueva, allá en la anterior. Se ve descuidado y molesta a tus compañeros.
GO TO FULL VERSION