Comas al inicio o al final en SQL

¿La coma va al final de una línea o al inicio de la siguiente? Esta guía compara ambos estilos en lo que realmente importa: los diffs, comentar líneas, detectar una coma faltante y la legibilidad, y termina con una lista de verificación para ayudar a tu equipo a decidir.

Pocas cuestiones de formato generan tantas discusiones como la posición de las comas. Ambos estilos producen exactamente la misma consulta para la base de datos; la diferencia está por completo en cómo las personas leen, editan y revisan el código. Eso la convierte en una decisión de equipo, no en un problema de corrección, y la mejor respuesta es la que tu equipo aplica de forma consistente.

Los dos estilos

Las comas al final (trailing commas) ponen la coma al final de cada línea, justo después del elemento al que siguen, igual que se usan las comas en un texto y en la mayoría de los lenguajes de programación. Las comas al inicio (leading commas, a veces llamadas comma-first) ponen la coma al inicio de la línea siguiente, justo delante del elemento que introducen. Esta es la misma consulta formateada de las dos maneras, con commas=after y commas=before:

select o.order_id, o.created_at, c.customer_name, c.email, o.total_amount from orders o join customers c on c.customer_id = o.customer_id where o.status = 'open' order by o.created_at, o.order_id;

SELECT o.order_id,
    o.created_at,
    c.customer_name,
    c.email,
    o.total_amount
FROM orders o
    JOIN customers c
        ON  c.customer_id = o.customer_id
WHERE o.status = 'open'
ORDER BY o.created_at,
    o.order_id;

SELECT o.order_id
    ,o.created_at
    ,c.customer_name
    ,c.email
    ,o.total_amount
FROM orders o
    JOIN customers c
        ON  c.customer_id = o.customer_id
WHERE o.status = 'open'
ORDER BY o.created_at
    ,o.order_id;

Solo cambian la lista del select y la lista del ORDER BY. En el estilo de coma inicial, el formateador escribe la coma justo delante del elemento, como ,o.created_at, sin espacio después. El resto de la disposición es idéntico. Puedes cambiar entre los dos estilos en cualquier momento con la opción Comas.

De dónde viene cada estilo

Las comas al final son el estándar casi en todas partes porque siguen los hábitos normales de escritura. La mayor parte del SQL que encuentras en documentación, libros de texto, consultas generadas por ORM y herramientas de bases de datos las usa, y la mayoría de las personas las escribe sin pensarlo siquiera.

Las comas al inicio son una elección deliberada. Suelen aparecer en equipos que escriben y mantienen mucho SQL hecho a mano, como reportes, data warehousing y analítica, donde las listas del select son largas y se agregan, quitan y comentan columnas todo el tiempo. La misma idea aparece en algunos otros lenguajes para listas que cambian con frecuencia. La motivación siempre es práctica: que las ediciones más comunes toquen la menor cantidad posible de líneas y que los delimitadores de la lista queden en una columna predecible.

Diffs: agregar y quitar el último elemento

Este es el argumento más citado a favor de las comas al inicio, y es real. Supón que agregas o.currency_code al final de una lista del select. Con comas al final, la línea que antes era la última tiene que ganar una coma, así que el diff muestra esa línea como modificada:

--- a/reports/open_orders.sql
+++ b/reports/open_orders.sql
@@ -1,4 +1,5 @@
 SELECT o.order_id,
     o.created_at,
-    o.total_amount
+    o.total_amount,
+    o.currency_code
 FROM orders o

Con comas al inicio, el nuevo elemento trae su propia coma y las líneas existentes no se tocan:

--- a/reports/open_orders.sql
+++ b/reports/open_orders.sql
@@ -1,4 +1,5 @@
 SELECT o.order_id
     ,o.created_at
     ,o.total_amount
+    ,o.currency_code
 FROM orders o

La versión con comas al final muestra dos líneas modificadas para un cambio de una sola columna, y ahora git blame atribuye o.total_amount a quien agregó currency_code. Quitar el último elemento es el caso inverso: el estilo de coma final también obliga a editar la nueva última línea para quitarle la coma. Sin embargo, el panorama completo es más equilibrado:

Las comas al inicio trasladan el problema del final de la lista al principio. Como el formateador mantiene el primer elemento del select en la línea del SELECT, cambiar el primer elemento toca esa línea en cualquiera de los dos estilos. En la práctica, las columnas se agregan al final con mucha más frecuencia que al principio, y por eso el argumento de los diffs favorece a las comas al inicio en el trabajo diario. Que esto importe o no depende de qué tan seguido cambian tus listas y de con cuánto detalle tu equipo lee los diffs.

Comentar líneas

Mientras exploras datos o depuras un reporte, es común desactivar una columna comentando su línea. Cada estilo tiene una posición en la que eso rompe la consulta. Con comas al final, es el último elemento, porque la línea anterior conserva una coma sin nada después:

-- Trailing commas: commenting out the LAST column breaks the query
SELECT o.order_id,
    o.created_at,
    o.total_amount,
--    o.currency_code
FROM orders o;

-- Commenting out the FIRST column is safe
SELECT
--    o.order_id,
    o.created_at,
    o.total_amount
FROM orders o;

Con comas al inicio, la última línea es segura y el problema es la primera, porque ahora el segundo elemento empieza con una coma:

-- Leading commas: commenting out the LAST column is safe
SELECT o.order_id
    ,o.created_at
    ,o.total_amount
--    ,o.currency_code
FROM orders o;

-- Commenting out the FIRST column breaks the query
SELECT
--    o.order_id
    ,o.created_at
    ,o.total_amount
FROM orders o;

Otra vez, la ventaja de las comas al inicio es de frecuencia: en el trabajo exploratorio, normalmente se activan y desactivan columnas cerca del final de la lista. Si tu flujo de trabajo implica comentar mucho, esta es una razón práctica para preferirlas. Si no, es un detalle menor.

Detectar una coma faltante

Una coma faltante es el error de comas que más duele, porque muchas veces no provoca ningún error. En la mayoría de las bases de datos, AS es opcional antes de un alias de columna, así que dos nombres de columna separados solo por espacios se interpretan como una columna y su alias:

-- Trailing commas: the missing comma hides at the end of a line
SELECT order_id,
    created_at
    total_amount,
    status
FROM orders;

-- Leading commas: the gap is visible in the left margin
SELECT order_id
    ,created_at
    total_amount
    ,status
FROM orders;

Las dos consultas se ejecutan. Las dos devuelven tres columnas en lugar de cuatro, y la columna llamada total_amount en realidad contiene created_at. En el estilo de coma final, la coma faltante está al final de una línea, donde la vista casi nunca se detiene, y las líneas de distinta longitud hacen que el hueco sea más difícil de ver. En el estilo de coma inicial, cada elemento después del primero empieza con una coma en la misma columna, así que la línea que no la tiene salta a la vista.

Dos hábitos te protegen sin importar el estilo que elijas: escribir AS antes de cada alias de columna, para que un alias sin AS se vea mal, y dejar que un formateador organice la lista con un elemento por línea. Un formateador no va a agregar una coma faltante, pero con cada elemento en su propia línea, una línea que contiene dos nombres es fácil de detectar.

Listas del SELECT vs listas IN

La posición de las comas también afecta a las listas de valores, no solo a las listas de columnas. El formateador aplica el estilo elegido a las listas que divide en varias líneas: la lista del select, los valores dentro de IN (...) y las listas de GROUP BY y ORDER BY:

select order_id, status, total_amount from orders where status in ('open', 'pending', 'on_hold') and region_id in (10, 20, 30) group by order_id, status, total_amount;

SELECT order_id,
    status,
    total_amount
FROM orders
WHERE status IN (
    'open',
    'pending',
    'on_hold'
)
AND region_id IN (
    10,
    20,
    30
)
GROUP BY order_id,
    status,
    total_amount;

SELECT order_id
    ,status
    ,total_amount
FROM orders
WHERE status IN (
    'open'
    ,'pending'
    ,'on_hold'
)
AND region_id IN (
    10
    ,20
    ,30
)
GROUP BY order_id
    ,status
    ,total_amount;

Las comas al inicio se leen con naturalidad en una lista del select larga, donde cada línea es una columna con significado. En una lista corta de valores literales se ven más pesadas, y a algunas personas ,'pending' les resulta más difícil de leer que 'pending',. Como una sola opción cubre todas estas listas, vale la pena formatear algunas de tus consultas reales de las dos maneras antes de decidir.

La opción llega más allá de las listas de columnas y de valores. También se aplica a las consultas con nombre de una cláusula WITH, a las expresiones CASE de una lista del select, a las listas SET y RETURNING, a las listas de columnas y de VALUES de un INSERT y a las definiciones de columnas de un CREATE TABLE. Dentro de una CTE o de una subconsulta, las comas se alinean en la sangría propia de ese bloque:

WITH order_totals AS (
    SELECT customer_id
        ,COUNT(*) AS order_count
        ,SUM(total_amount) AS revenue
    FROM orders
    GROUP BY customer_id
)
,segments AS (
    SELECT customer_id
        ,revenue
        ,CASE WHEN revenue >= 10000 THEN
            'key'
        WHEN revenue >= 1000 THEN
            'regular'
        ELSE
            'occasional'
        END AS segment
    FROM order_totals
)
SELECT s.customer_id
    ,s.segment
    ,s.revenue
FROM segments s
ORDER BY s.revenue DESC

Fíjate dónde va la coma entre las dos CTE: delante del segundo nombre, como ,segments AS (, en lugar de después del paréntesis de cierre de la primera.

Legibilidad y costumbre

Los argumentos de legibilidad funcionan en ambas direcciones. Quienes defienden las comas al inicio valoran el borde izquierdo limpio: los elementos de la lista quedan alineados y la columna de comas funciona como un marcador visual de "esta línea continúa la lista". Quienes defienden las comas al final señalan que coincide con la forma en que todo el mundo escribe listas en otros lenguajes y en texto común, así que los nuevos integrantes del equipo, los generadores de código y la documentación ya la usan. Ninguna de las dos posturas está equivocada, y normalmente gana la costumbre: después de unas semanas, la mayoría de las personas encuentra perfectamente legible el estilo que usa todos los días.

Lo que sí reduce la legibilidad es mezclar los dos. Un archivo en el que algunas consultas usan comas al inicio y otras comas al final obliga a cada lector a detenerse y adaptarse. Por eso la decisión debe tomarse una sola vez, por repositorio, y luego aplicarse mediante el formateo y no de memoria.

Lista de verificación para decidir en equipo

Revisa estas preguntas con tu equipo y luego deja la respuesta por escrito junto a las demás convenciones de SQL del equipo:

1. ¿Qué usa el código existente? Si la mayor parte del código ya usa un estilo, cambiar tiene un costo: un commit grande de reformateo y un período de adaptación. Cambia solo si hay una razón clara.
2. ¿Con qué frecuencia cambian tus listas? Las listas del select largas y editadas con frecuencia (reportes, pipelines de datos) se benefician más de las comas al inicio que las consultas de aplicación cortas y estables.
3. ¿Cuánta edición exploratoria se hace? Si la gente comenta y descomenta columnas a menudo, las comas al inicio evitan errores pequeños pero frecuentes.
4. ¿Con cuánto detalle leen los diffs y el blame? Si las revisiones son línea por línea y el historial importa, los diffs de una sola línea de las comas al inicio son un beneficio real.
5. ¿De dónde más viene el SQL? El SQL generado, los fragmentos de la documentación y las consultas de herramientas usarán en su mayoría comas al final. Decide si los vas a reformatear al incorporarlos.
6. ¿Una herramienta lo puede aplicar? Elige un estilo que tu formateador soporte, para que nadie tenga que aplicarlo a mano. Los dos estilos están disponibles en SQL Format.
7. ¿Está por escrito? Registra la decisión, junto con las demás opciones de formato, en el repositorio, donde todos puedan encontrarla.

Preguntas frecuentes

Para saber más sobre cómo mantener pequeños los diffs de SQL y las revisiones enfocadas, lee formatear SQL para revisión de código y control de versiones. La guía de estilo de SQL cubre las demás convenciones que vale la pena acordar al mismo tiempo.