Opción Comas

La opción Comas decide si cada coma va al final de una línea (comas al final, el valor predeterminado) o al inicio de la siguiente (comas al inicio). Esta página muestra las dos salidas, dónde se aplica la opción y las ventajas y desventajas prácticas, para que puedas elegir un estilo para tu equipo.

Qué hace la opción

Cada vez que el formateador pone los elementos de una lista separada por comas en líneas distintas, tiene que decidir qué línea lleva la coma. La opción toma esa decisión para todas las listas de ese tipo en la sentencia:

• la lista del select;
• las listas de GROUP BY y ORDER BY;
• los argumentos de una función, cuando la llamada se divide en un argumento por línea;
• las listas de valores como IN ('OPEN', 'FROZEN'), que también se dividen en un valor por línea;
• la lista SET de un UPDATE, la lista RETURNING y las listas de columnas y de VALUES de un INSERT;
• las definiciones de columnas en CREATE TABLE (,amount NUMERIC(12, 2));
• las consultas con nombre de una cláusula WITH (,ranked AS ();
• los elementos del select que son expresiones CASE (,CASE WHEN).

La misma regla se aplica a cualquier profundidad: dentro de una CTE o de una subconsulta, las comas quedan en la columna de sangría propia de ese bloque.

No cambia nada más: los saltos de línea, la sangría y las mayúsculas o minúsculas de las palabras clave son iguales en los dos modos.

Valores posibles y valor predeterminado

Esta es la misma consulta de reporte en los dos estilos:

select c.id, c.email, c.country_code, count(o.id) as order_count, sum(o.total) as lifetime_value from customers c left join orders o on o.customer_id = c.id group by c.id, c.email, c.country_code order by lifetime_value desc, c.id

SELECT c.id,
    c.email,
    c.country_code,
    COUNT(o.id) AS order_count,
    SUM(o.total) AS lifetime_value
FROM customers c
    LEFT JOIN orders o
        ON  o.customer_id = c.id
GROUP BY c.id,
    c.email,
    c.country_code
ORDER BY lifetime_value DESC,
    c.id

SELECT c.id
    ,c.email
    ,c.country_code
    ,COUNT(o.id) AS order_count
    ,SUM(o.total) AS lifetime_value
FROM customers c
    LEFT JOIN orders o
        ON  o.customer_id = c.id
GROUP BY c.id
    ,c.email
    ,c.country_code
ORDER BY lifetime_value DESC
    ,c.id

En ambas salidas, el primer elemento se queda en la línea de su palabra clave (SELECT c.id, GROUP BY c.id, ORDER BY lifetime_value DESC). Con comas al inicio, cada elemento siguiente empieza con una coma en la columna de sangría, así que las comas forman una línea vertical recta.

Las comas al inicio se aplican de la misma forma a los argumentos de funciones y a las listas de valores:

SELECT id
    ,COALESCE(
        nickname
        ,first_name
    ) AS display_name
    ,round(
        balance
        ,2
    ) AS balance
FROM accounts
WHERE status IN (
    'OPEN'
    ,'FROZEN'
)

Comas al final: ventajas y desventajas

Las comas al final siguen la puntuación normal, así que la consulta se lee como una enumeración en un texto. Es el estilo que usa la mayor parte de la documentación de bases de datos, el SQL generado por herramientas y la mayoría de los desarrolladores que nunca se plantearon la cuestión. Alguien nuevo que lea tu código no se va a detener en eso.

El costo aparece al final de la lista. El último elemento no lleva coma, así que se comporta distinto de todos los demás. Coméntalo mientras depuras y el elemento anterior queda con una coma justo delante de FROM:

SELECT c.id,
    c.email,
    c.country_code,
    COUNT(o.id) AS order_count,
    -- SUM(o.total) AS lifetime_value
FROM customers c
    LEFT JOIN orders o
        ON  o.customer_id = c.id

La mayoría de las bases de datos, incluidas PostgreSQL, MySQL, SQL Server y Oracle, rechaza esa sentencia con un error de sintaxis cerca de FROM. Es uno de los errores de SQL autoinfligidos más comunes, y puede repetirse cada vez que alguien agrega o quita la última columna y se olvida de la coma de la línea anterior.

Comas al inicio: ventajas y desventajas

Las comas al inicio trasladan el caso especial del último elemento al primero. Cada elemento después del primero lleva su propia coma, así que quitar o comentar la última línea deja un SQL válido:

SELECT c.id
    ,c.email
    ,c.country_code
    ,COUNT(o.id) AS order_count
    -- ,SUM(o.total) AS lifetime_value
FROM customers c
    LEFT JOIN orders o
        ON  o.customer_id = c.id

La línea vertical de comas también hace que una coma faltante sea fácil de detectar. Eso importa más de lo que parece: en la mayoría de las bases de datos, AS es opcional para los alias de columna, así que olvidar una coma entre dos columnas no provoca un error. Convierte silenciosamente la segunda columna en un alias de la primera. Con comas al inicio, el hueco en la columna de comas se ve de un vistazo; con comas al final, queda escondido en el borde derecho irregular.

Las desventajas son la costumbre y el gusto. A muchos desarrolladores les resulta raro que una línea empiece con un signo de puntuación, y el código copiado de la documentación o de otros proyectos va a estar en el otro estilo hasta que se formatee. Además, el problema no desaparece, se traslada: quitar o comentar el primer elemento sigue obligando a editar la línea del SELECT.

Efecto en los diffs y en la revisión de código

La diferencia se ve con más claridad en el control de versiones. Con la disposición anterior, esta es la cantidad de líneas que cambian en las ediciones más comunes:

Las columnas se agregan al final de una lista mucho más seguido que al principio, así que las comas al inicio producen diffs un poco más pequeños y menos comentarios de revisión por una coma suelta. El efecto es real pero modesto; la consistencia en todo el código importa más. La guía de revisión de código y control de versiones explica cómo cambiar de estilo sin llenar el historial de ruido.

Cuál elegir

Los dos estilos aparecen en guías de estilo publicadas por equipos, y ninguno está mal. Las comas al inicio tienen muchos seguidores en los equipos de datos y analítica que editan listas largas del select todo el día; las comas al final siguen siendo la opción más común en otros ámbitos. Como regla general:

• Elige comas al final si el SQL lo leen sobre todo desarrolladores de aplicaciones, si está incrustado en otro código o si quieres una salida que se parezca a la documentación.
• Elige comas al inicio si tu equipo escribe consultas de reporte largas, comenta y descomenta columnas mientras explora datos o ya sufrió el problema del alias por una coma faltante.

Elijas el que elijas, deja que el formateador lo aplique, para que nadie tenga que recordar la regla. La guía de comas al inicio y comas al final profundiza en la historia y en los argumentos de cada lado. Las demás opciones están documentadas en las páginas de Espacios de sangría, Cantidad máxima de columnas, Palabras clave y Paréntesis en nueva línea.