Un jour sur Stack Overflow : La malédiction des longues chaînes en C#
\n\nImaginez la situation. Vous écrivez en C# un JSON de configuration, une requête SQL ou, disons, un modèle HTML directement dans le code. La chaîne devient longue, moche et totalement illisible. Vous appuyez sur Entrée pour passer à la ligne... et vous obtenez une erreur de compilation. Familier ?
\n\nLa question "Multiline string literal in C#" sur Stack Overflow a recueilli des dizaines de milliers de vues. Et ce n'est pas un hasard. Pendant longtemps, C# n'a pas été le langage le plus convivial pour travailler avec du texte multiligne. Mais les temps changent. Dans cet article, nous passerons des solutions de fortune aux solutions élégantes apparues dans C# 11.
\n\nSi vous écrivez en C# et travaillez avec des littéraux de chaîne multilignes, ce contenu vous fera gagner des heures de recherche Google. C'est parti !
\n\nLe problème : Pourquoi appuyer simplement sur Entrée est une mauvaise idée ?
\n\nEn C# (comme en C++), un littéral de chaîne est une séquence de caractères entre guillemets. Un saut de ligne à l'intérieur de ces guillemets est une erreur de syntaxe. Le compilateur ne comprendra tout simplement pas où la chaîne se termine.
\n\nVoici comment NE PAS faire :
\n\n// Erreur de compilation !\nstring query = "SELECT * FROM Users\nWHERE Age > 18\nORDER BY Name";\n\nLe compilateur verra "SELECT * FROM Users — et c'est tout. Ensuite, c'est le chaos. Avant, les développeurs se débrouillaient comme ils pouvaient. Analysons l'évolution des solutions.
L'ancienne méthode : Verbatim string (chaîne @) — la bouée de sauvetage
\n\nLa première chose qui vient à l'esprit est le verbatim string literal. Vous placez simplement @ avant le guillemet ouvrant. Cela désactive l'interprétation des séquences d'échappement (sauf pour les guillemets doubles "").
Mais il y a un hic : les indentations deviennent également une partie de la chaîne.
\n\nExemple avec verbatim string :
\n\nstring json = @"{\n ""name"": ""Alice"",\n ""age"": 30\n}";\nConsole.WriteLine(json);\n\nSortie :
\n{\n "name": "Alice",\n "age": 30\n}\n\nAvantages :
\n- \n
- Fonctionne dans toutes les versions de C#. \n
- Pas besoin d'échapper la barre oblique inverse (
\\). \n
Inconvénients :
\n- \n
- Les guillemets à l'intérieur doivent être doublés (
"") — c'est horrible s'il y a beaucoup de JSON. \n - Les indentations à gauche (espaces/tabulations) se retrouvent dans la chaîne finale. \n
- Impossible de mélanger directement avec l'interpolation de chaînes (
$) (mais$@est possible). \n
Cette méthode est encore populaire, mais pour un code propre, elle n'est pas idéale. La véritable percée a eu lieu avec C# 11.
\n\nLa méthode la plus récente : Raw string literal (C# 11 et .NET 7+)
\n\nDepuis C# 11, nous avons le raw string literal — littéralement "littéral de chaîne brute". Il résout 99% des problèmes de multiligne.
\n\nSyntaxe : trois guillemets doubles ou plus à la suite (""").
Exemple 1 : JSON simple sans échappement
\n\nstring json = """\n {\n "name": "Alice",\n "age": 30\n }\n """;\nConsole.WriteLine(json);\n\nSortie :
\n{\n "name": "Alice",\n "age": 30\n}\n\nMagie : Les guillemets à l'intérieur de la chaîne n'ont pas besoin d'être doublés ! Le compilateur comprend que la chaîne est terminée uniquement lorsqu'il voit trois guillemets à la suite.
\n\nExemple 2 : Requête SQL avec indentations
\n\nstring query = """\n SELECT \n u.Name,\n o.OrderDate\n FROM Users u\n JOIN Orders o ON u.Id = o.UserId\n WHERE o.Status = 'Active'\n ORDER BY o.OrderDate DESC\n """;\nConsole.WriteLine(query);\n\nImportant concernant les indentations : Les guillemets fermants (""") définissent le niveau de base de l'indentation. Toutes les lignes qui ont une indentation inférieure à celle des guillemets fermants seront tronquées. Cela permet de conserver la lisibilité du code sans encombrer la chaîne avec des espaces supplémentaires.