Una vez en Stack Overflow: La maldición de las cadenas largas en C#
Imagina la situación. Estás escribiendo en C# un JSON de configuración, una consulta SQL o, digamos, una plantilla HTML directamente en el código. La cadena se vuelve larga, fea y absolutamente ilegible. Presionas Enter para saltar de línea... y obtienes un error de compilación. ¿Te suena familiar?
La pregunta "Multiline string literal in C#" en Stack Overflow ha acumulado decenas de miles de visitas. Y no es casualidad. Durante mucho tiempo, C# no fue el lenguaje más amigable para trabajar con texto multilínea. Pero los tiempos cambian. En este artículo, recorreremos el camino desde soluciones improvisadas hasta las elegantes que aparecieron en C# 11.
Si escribes en C# y trabajas con literales de cadena multilínea, este material te ahorrará horas de búsqueda en Google. ¡Allá vamos!
El problema: ¿Por qué simplemente presionar Enter es una mala idea?
En C# (al igual que en C++), un literal de cadena es una secuencia de caracteres encerrada entre comillas. Un salto de línea dentro de esas comillas es un error de sintaxis. El compilador simplemente no entenderá dónde termina la cadena.
Así es como NO se debe hacer:
// ¡Error de compilación!string query = "SELECT * FROM UsersWHERE Age > 18ORDER BY Name";El compilador verá "SELECT * FROM Users — y listo. El resto es un caos. Antiguamente, los desarrolladores se las ingeniaban como podían. Analicemos la evolución de las soluciones.
El método antiguo: Verbatim string (cadena @) — el salvavidas
Lo primero que viene a la mente es el verbatim string literal. Simplemente colocas @ antes de la comilla de apertura. Esto desactiva la interpretación de secuencias de escape (excepto las comillas dobles "").
Pero hay un detalle: la sangría también se convierte en parte de la cadena.
Ejemplo con verbatim string:
string json = @"{ ""name"": ""Alice"", ""age"": 30}";Console.WriteLine(json);Salida:
{ "name": "Alice", "age": 30}Ventajas:
- Funciona en todas las versiones de C#.
- No es necesario escapar la barra invertida (
\\).
Desventajas:
- Las comillas internas deben duplicarse (
"") — esto es horrible si hay mucho JSON. - La sangría izquierda (espacios/tabulaciones) se incluye en la cadena final.
- No se puede mezclar directamente con interpolación de cadenas (
$) (pero se puede usar$@).
Este método sigue siendo popular, pero para código limpio no es ideal. El verdadero avance ocurrió en C# 11.
El método más nuevo: Raw string literal (C# 11 y .NET 7+)
A partir de C# 11, tenemos el raw string literal — literalmente "literal de cadena crudo". Resuelve el 99% de los problemas de multilínea.
Sintaxis: tres o más comillas dobles consecutivas (""").
Ejemplo 1: JSON simple sin escape
string json = """ { "name": "Alice", "age": 30 } """;Console.WriteLine(json);Salida:
{ "name": "Alice", "age": 30}Magia: ¡Las comillas dentro de la cadena no necesitan duplicarse! El compilador entiende que la cadena terminó solo cuando ve tres comillas consecutivas.
Ejemplo 2: Consulta SQL con sangría
string query = """ SELECT u.Name, o.OrderDate FROM Users u JOIN Orders o ON u.Id = o.UserId WHERE o.Status = 'Active' ORDER BY o.OrderDate DESC """;Console.WriteLine(query);Importante sobre la sangría: Las comillas de cierre (""") establecen el nivel base de sangría. Todas las líneas que tengan menos sangría que las comillas de cierre se recortarán. Esto permite mantener la legibilidad del código sin saturar la cadena con espacios innecesarios.