Nivel inicial11 min de lectura · Publicado el 17 de agosto de 2018

Formato del código en código limpio: reglas y herramientas

El código se lee muchas más veces de las que se escribe. Si cada fichero tiene un aspecto distinto, cada lectura empieza con un pequeño esfuerzo extra: averiguar dónde está cada cosa.

El formato es como la maquetación de un libro. Dos libros pueden contar la misma historia, pero el que tiene párrafos, capítulos y márgenes se lee de un tirón; el que lo mete todo en un bloque de texto se abandona en la página dos.

Estas reglas se basan en el capítulo 5, «Formatting», de Clean Code, de Robert C. Martin. Aquí están explicadas con palabras propias y con ejemplos en Java compilados. Forma parte de la guía de código limpio (clean code), con todos los principios y un ejemplo de cada uno.

Formato vertical: de arriba abajo

Número de líneas por fichero

Los ficheros pequeños se entienden mejor que los grandes. Martin midió varios proyectos en Java y vio que en algunos, como JUnit o FitNesse, ningún fichero pasaba de 500 líneas y la mayoría tenía menos de 200.

De ahí sale su recomendación: ficheros de unas 200 líneas, con un máximo de unas 500. No es una regla obligatoria, es una orientación. Si un fichero crece mucho más, suele ser señal de que hace demasiadas cosas.

El símil del periódico

Un buen fichero se lee como una noticia de periódico:

• El titular es el nombre de la clase. Te dice de qué va y si estás en el sitio correcto.
• Los primeros párrafos son los métodos de arriba. Dan la idea general sin entrar en detalles.
• Según bajas, aparecen los detalles: las funciones más pequeñas y concretas quedan al final.

Un periódico tiene muchas noticias cortas por página. Si fuera un único artículo enorme, nadie lo leería. Con el código pasa lo mismo: una clase que lo mete todo dentro hace muy difícil encontrar lo que te interesa.

Separación vertical: una línea en blanco por idea

Las líneas en blanco separan conceptos. Cada una le dice al lector: «aquí empieza otra cosa».

String getNombre() {
    return nombre;
}

String getApellido() {
    return apellido;
}

int getEdad() {
    return edad;
}

String getNombre() {
    return nombre;
}
String getApellido() {
    return apellido;
}
int getEdad() {
    return edad;
}

Sin líneas en blanco, los métodos se funden y cuesta ver dónde acaba uno y empieza el siguiente.

Densidad vertical: lo que va junto, sin huecos

Es la regla contraria: las líneas muy relacionadas deben ir pegadas. Aquí ves de un vistazo que la clase tiene dos atributos:

class Contacto {
    String nombre;
    String telefono;
}

Si metes comentarios que no aportan nada, los atributos se separan y tienes que recorrer el código para reconstruir algo tan simple:

class Contacto {
    /**
     * El nombre
     * del contacto
     */
    String nombre;

    /**
     * El teléfono
     * del contacto
     */
    String telefono;
}

Sobre cuándo un comentario aporta y cuándo estorba, tienes más en Comentarios en código limpio.

Distancia vertical: cada cosa cerca de donde se usa

Los conceptos relacionados deben estar cerca unos de otros en el mismo fichero. No los separes en ficheros distintos sin un buen motivo, porque obligas al lector a saltar de un sitio a otro.

Con las variables:

• Variables locales: lo más cerca posible de donde se usan. Como las funciones deberían ser cortas, eso suele ser al principio de la función.
• Variables de un bucle: dentro de la propia instrucción del bucle, como for (double precio : precios).
• Atributos de la clase: en un sitio que todo el mundo conozca. En Java, arriba del todo. Martin cuenta que en C++ había quien los ponía al final, y no le convence: lo importante es que estén siempre en el mismo sitio.

También deben ir cerca las funciones con afinidad conceptual: una que llama a otra, o varias que hacen operaciones parecidas (como los tres get del ejemplo anterior).

Orden vertical: quien llama, arriba

Si una función llama a otra, la que llama va encima y cerca. Así el código se lee de arriba abajo, como un libro: primero lo general y, al bajar, los detalles.

class Pedido {
    private static final double IGIC = 0.07;

    private final List<Double> precios;

    Pedido(List<Double> precios) {
        this.precios = precios;
    }

    double total() {
        double base = sumarPrecios();
        return base + impuesto(base);
    }

    private double sumarPrecios() {
        double suma = 0;
        for (double precio : precios) {
            suma += precio;
        }
        return suma;
    }

    private double impuesto(double base) {
        return base * IGIC;
    }
}

Lees total() y ya sabes qué hace la clase. Si quieres el detalle de cómo suma o cómo calcula el impuesto, sigues bajando. Este ejemplo usa también las reglas anteriores: atributos arriba, suma justo antes de usarse y precio dentro del bucle.

Formato horizontal: a lo ancho

Ancho de línea

No deberías tener que hacer scroll horizontal para leer una línea. Tampoco vale escribir líneas enormes porque tu monitor es ancho: tus compañeros no tienen por qué tener el mismo.

Martin considera que el límite clásico de 80 caracteres es algo arbitrario, acepta 100 o 120 y él se pone 120 como máximo. Prettier, la herramienta de formato que verás más abajo, usa 80 por defecto y recomienda no pasar de ahí. Cualquiera de los dos límites es razonable; lo importante es que el equipo elija uno.

Espacios en blanco horizontales

Los espacios unen lo que está muy relacionado y separan lo que lo está menos:

total+=(precio+igic)      // sin espacios: todo pegado
total += (precio + igic)  // con espacios: se ven las dos partes del +=

Los espacios alrededor de += separan claramente lo que hay a cada lado. Dentro de los paréntesis no se dejan espacios, para que se vea que su contenido va junto.

Alineación horizontal: mejor no

Quizá hayas leído que alinear en columnas da homogeneidad, pero Martin explica justo lo contrario. Él alineaba así las declaraciones y lo dejó:

class ContactoAlineado {
    String    nombre;
    String    telefono;
    int       edad;
    boolean   activo;
}

El motivo es que la alineación lleva la vista a recorrer columnas (todos los nombres, todos los tipos) en vez de leer cada línea entera. Además, en cuanto añades un atributo con un tipo más largo, tienes que realinear todo y el cambio ensucia el historial. Si la lista es tan larga que parece necesitar alineación, el problema suele ser que la clase hace demasiado.

Prettier también lo resuelve por ti: al formatear esa clase quita los espacios de alineación y deja un solo espacio entre tipo y nombre.

Sangrado

El sangrado muestra la jerarquía del código: lo que pertenece a un bloque se desplaza un nivel a la derecha. Sin sangrado, un programa sería casi imposible de leer.

No lo rompas ni siquiera en bloques muy cortos. Meterlo todo en una línea ahorra espacio, pero esconde la estructura:

if (tamanoMedido <= tamanoMaximo) {
    return "Tamaño válido";
}

if (tamanoMedido <= tamanoMaximo) { return "Tamaño válido"; }

El equipo manda sobre el gusto de cada uno.

Reglas de equipo

Cada programador tiene sus manías: llaves en la misma línea o en la siguiente, dos o cuatro espacios. Pero en un equipo, el equipo manda.

Antes de empezar un proyecto, poneos de acuerdo en un estilo y que todo el código lo siga. Martin cuenta que en FitNesse lo acordaron en unos diez minutos y lo configuraron en el formateador del IDE. El código de un proyecto debe parecer escrito por una sola persona.

La diferencia hoy es que ese acuerdo no tiene que vivir en la memoria de nadie: se escribe en un fichero y lo aplica una herramienta.

Automatiza el formato

1. Acordad lo básico en un .editorconfig.
2. Dejad que un formateador aplique el resto.
3. Comprobadlo automáticamente antes de integrar cambios.

EditorConfig: lo básico para cualquier editor

EditorConfig es un fichero de texto, .editorconfig, en la raíz del proyecto. Define lo básico (espacios o tabuladores, tamaño del sangrado, saltos de línea, codificación) y lo entienden muchos editores; IntelliJ IDEA, sin instalar nada. Un ejemplo:

root = true

[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true
indent_style = space
indent_size = 2
max_line_length = 120

[*.java]
indent_size = 4

max_line_length no está en la lista básica de EditorConfig, pero Prettier lo usa como su ancho de línea.

Prettier: el formateador que no discute

Prettier reescribe el código con un estilo fijo, con muy pocas opciones que elegir. Justo por eso acaba con las discusiones de estilo. Formatea JavaScript, TypeScript, CSS, HTML, JSON o Markdown; para Java existe el plugin prettier-plugin-java.

Si tu proyecto tiene .editorconfig, Prettier lo lee y respeta el sangrado, el ancho de línea y los saltos de línea que pongas ahí.

npm install --save-dev prettier prettier-plugin-java
echo '{ "plugins": ["prettier-plugin-java"] }' > .prettierrc.json

npx prettier --check .   # avisa de los ficheros mal formateados
npx prettier --write .   # los formatea

Con este fichero, todo pegado y en pocas líneas:

class Paquete {
int tamanoMedido;int tamanoMaximo;
String validar(){
if(tamanoMedido<=tamanoMaximo){return "Tamaño válido";}
return "Demasiado grande";}
}

npx prettier --write . lo deja así, con los cuatro espacios del .editorconfig:

class Paquete {

    int tamanoMedido;
    int tamanoMaximo;

    String validar() {
        if (tamanoMedido <= tamanoMaximo) {
            return "Tamaño válido";
        }
        return "Demasiado grande";
    }
}

Ten en cuenta su límite: un formateador cambia el aspecto, no el significado. No añade llaves a un if que no las tiene ni divide una clase demasiado grande. Para eso están los linters y, sobre todo, tu criterio.

--check devuelve un error si algún fichero no cumple el estilo, así que puedes ponerlo en la integración continua para que nadie integre código sin formatear.

Formatear código en IntelliJ IDEA

IntelliJ trae su propio formateador y usa el .editorconfig del proyecto; lo que no esté ahí lo toma de los ajustes de estilo del proyecto.

Para no tener que acordarte, haz que formatee al guardar:

1. Abre los ajustes con Ctrl + Alt + S (⌘ + , en Mac).
2. Ve a Tools | Actions on Save.
3. Activa Reformat code. Si quieres, en Configure scope elige Changed lines para formatear solo las líneas que has cambiado.

También puedes formatear al hacer commit: en la ventana de commit, en las opciones de comprobación, marca Reformat code.

Si el proyecto usa Prettier, conviene que IntelliJ también lo use, para que el IDE y la integración continua no se peleen. Tienes más atajos en Atajos de teclado de IntelliJ IDEA.

Formato y programación con IA

Cuando un agente de IA escribe parte del código, el formato importa todavía más, porque vas a revisar mucho código que no has escrito tú. En el enfoque de IA Limpia, el criterio es no pedirle al agente que formatee bien, sino hacer que el formateador del proyecto pase siempre sobre su código, igual que sobre el tuyo. Así el estilo no depende de lo que el modelo haya decidido ese día y, al revisar, los cambios que ves son de lógica y no de espacios.

Las reglas de fondo siguen siendo tuyas: ficheros cortos, lo general arriba y los detalles abajo. Eso ninguna herramienta lo arregla por ti.

Fuentes

Comprobado en noviembre de 2026:

• Robert C. Martin, Clean Code (2008), capítulo 5, «Formatting». Las ideas están explicadas con palabras propias, sin citas literales. Los datos del capítulo (200 y 500 líneas, 120 caracteres, los diez minutos de FitNesse) se han contrastado con una traducción del capítulo y con resúmenes, no con el original en inglés.
• EditorConfig: propiedades admitidas y editores con soporte nativo.
• Prettier 3.9.10: Configuration File (uso de .editorconfig) y Options (ancho de línea por defecto, 80).
• IntelliJ IDEA 2026.3: Reformat and rearrange code y atajos de macOS. Los atajos y los ajustes de IntelliJ están comprobados en la documentación, no ejecutados.

Ejecutado: los ejemplos de Java se han compilado y ejecutado con OpenJDK 21.0.13 (imagen eclipse-temurin:21). Los ejemplos de formato se han pasado por Prettier 3.9.10 con prettier-plugin-java 2.11.0 en Node 24.21.0, con el .editorconfig de este artículo.