Formateador de SQL

Un formateador que pone en mayúsculas palabras clave comparando palabras completas con una expresión regular no tiene forma de saber si una aparición dada de "order" es la palabra clave SQL `ORDER` (como en `ORDER BY`) o un valor de cadena literal que resulta contener esa palabra — una consulta que filtra filas `WHERE description = 'the order from stock'` tiene la palabra "order" dentro de una cadena entrecomillada, sin funcionar en absoluto como palabra clave. Un formateador ingenuo pone en mayúsculas cada palabra coincidente sin importar el contexto, corrompiendo el valor de cadena literal en `'the ORDER FROM stock'` y cambiando silenciosamente lo que la consulta realmente filtra. Tokenizar correctamente la consulta — reconociendo los límites de cadenas entrecomilladas antes de decidir qué cuenta como palabra clave — es lo que previene esto, y es precisamente la clase de error que solo aparece con datos reales que contienen palabras que resultan coincidir con palabras clave SQL, por lo que es fácil pasarlo por alto al probar con consultas de ejemplo simples.

Esta herramienta reconoce la estructura de cláusulas común compartida entre PostgreSQL, MySQL, SQL Server, SQLite y Oracle — SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY y sus parientes — lo bastante bien como para indentar cada cláusula en su propia línea y anidar correctamente las subconsultas. No construye una comprensión completa de la gramática completa de ninguna base de datos específica, incluyendo extensiones específicas de proveedor como la sintaxis de array de PostgreSQL o la colocación de la cláusula `TOP` de SQL Server. La consecuencia práctica es que la sintaxis específica de un dialecto pasa a través del formateador sin tocar en lugar de causar un error, pero tampoco recibirá la misma indentación cuidadosa que las cláusulas comunes — un intercambio razonable por soportar cinco dialectos con un solo formateador en lugar de necesitar una herramienta separada por motor de base de datos.

Las palabras clave SQL no distinguen mayúsculas y minúsculas por la propia especificación del lenguaje — `SELECT`, `Select` y `select` son idénticas para cualquier motor SQL — que es precisamente lo que hace que ponerlas en mayúsculas o minúsculas sea una operación puramente cosmética sin ningún riesgo de alterar el comportamiento. Lo mismo ocurre con los espacios en blanco y saltos de línea que añade este formateador: una consulta repartida en doce líneas indentadas se ejecuta idénticamente a la misma consulta amontonada en una. Nada del formateo toca los tokens reales que determinan qué tablas se leen, qué condiciones filtran filas, o qué valores se insertan — solo cómo se dispone visualmente esa misma consulta lógica para un humano que la lee después.

Una consulta generada por un ORM, exportada desde una interfaz gráfica de base de datos, o escrita como una sola línea extensa durante una migración apresurada suele ser funcionalmente correcta pero genuinamente difícil de revisar para una persona tal como está escrita — una consulta con quince joins sin saltos de línea dificulta ver qué condiciones pertenecen a qué join, o si una cláusula WHERE está filtrando la tabla correcta. Reformatearla con cada cláusula y cada join en su propia línea, indentada para reflejar la estructura real de la consulta, suele ser la forma más rápida de entender realmente lo que hace una consulta larga generada antes de aprobarla en una revisión de código o depurar por qué devuelve las filas equivocadas.