SQL es famoso por escribirse una vez con prisa y leerse muchas veces bajo presión. Un formato consistente es una de las formas más económicas de hacer que las consultas sean revisables, depurables y compartibles. Esta guía explica por qué importa el formato, las convenciones detrás de la capitalización de palabras clave y cuándo recurrir a la minimización.

Las consultas legibles mejoran los code reviews

Una consulta agrupada en una línea oculta su propia estructura. Cuando cada cláusula: SELECCIONAR, DESDE, cada ÚNETE, DONDE, Agrupar por: comienza en su propia línea, un revisor puede ver de un vistazo qué tablas están unidas, en qué claves y qué filtros se aplican. Sangrar la lista de selección y las condiciones de unión agrega una segunda capa de estructura: puede escanear las columnas sin analizar toda la declaración. El resultado son menos errores omitidos (una condición de unión olvidada es obvia cuando ON se encuentra en su propia línea sangrada) y revisiones más rápidas. El formateador está diseñado para cambiar solo los espacios en blanco y las mayúsculas y minúsculas de las palabras clave reconocidas, pero es el procesamiento de texto más eficaz en lugar de un analizador SQL, así que revise el resultado y valide las consultas importantes con las herramientas de su base de datos.

Convenciones de capitalización de palabras clave

La convención de larga data es escribir las palabras clave SQL en MAYÚSCULAS y los identificadores (tablas, columnas, alias) en minúsculas o mayúsculas mixtas. El contraste hace que el andamiaje del lenguaje resalte frente a tu esquema. Algunos equipos prefieren SQL completamente en minúsculas para un aspecto más suave, y unos pocos usan palabras clave Capitalizadas. No hay una única opción correcta — lo que importa es la coherencia en todo un código base, que es precisamente por qué un formateador que aplica una sola regla en todas partes es tan útil. Esta herramienta solo re-capitaliza las palabras clave reconocidas; los nombres de tus tablas y columnas conservan la capitalización que ya tienen, y nada dentro de un literal de cadena o comentario se modifica jamás.

Cuándo minimizar

Minimizar — contraer una consulta a una sola línea — es lo opuesto a embellecer, y tiene su lugar. Cuando una consulta debe vivir dentro del código fuente de una aplicación como constante de cadena, dentro de un valor de configuración JSON o YAML, o en un comando de shell de una línea, los saltos de línea estorban. Minimizar elimina el espacio en blanco de formato y conserva el contenido de los literales de cadena. También elimina los comentarios, porque un comentario de una sola línea (--) haría que todo lo posterior quedara comentado; revisa el resultado y valida las consultas importantes con tus herramientas de base de datos en lugar de asumir que toda entrada conserva exactamente la misma semántica. Si necesitas la versión legible de vuelta, simplemente pega la consulta minimizada en la pestaña Embellecer.

Un formateador no es un validador

Vale la pena aclarar los límites. Esta herramienta formatea texto — no se conecta a una base de datos, no ejecuta tu consulta ni comprueba que sea SQL válido. Si pegas algo que no puede analizar completamente, igualmente aplica el mejor espaciado posible y marca el resultado como un formato parcial en lugar de fallar. Eso lo hace seguro y rápido para el uso diario, pero aún debes ejecutar tu consulta en una base de datos real (o un linter) para confirmar su corrección. Piensa en el formateo como el primer paso, el más económico, para escribir SQL limpio, no como la última palabra sobre si funciona.