Pour un cas simple où il s'agit d'une simple concaténation unique, je pense que cela ne vaut pas la complexité de string.Format
(et je n'ai pas testé, mais je soupçonne que pour un cas simple comme celui-ci, cela string.Format
pourrait être légèrement plus lent, avec l'analyse de la chaîne de format et tout). Comme Jon Skeet, je préfère ne pas appeler explicitement .ToString()
, car cela sera fait implicitement par la string.Concat(string, object)
surcharge, et je pense que le code est plus propre et plus facile à lire sans lui.
Mais pour plus de quelques concaténations (combien est subjectif), je préfère définitivement string.Format
. À un certain moment, je pense que la lisibilité et les performances souffrent inutilement de la concaténation.
S'il y a beaucoup de paramètres dans la chaîne de format (encore une fois, "beaucoup" est subjectif), je préfère généralement inclure des indices commentés sur les arguments de remplacement, de peur de perdre la trace de quelle valeur va à quel paramètre. Un exemple artificiel:
Console.WriteLine(
"Dear {0} {1},\n\n" +
"Our records indicate that your {2}, \"{3}\", is due for {4} {5} shots.\n" +
"Please call our office at 1-900-382-5633 to make an appointment.\n\n" +
"Thank you,\n" +
"Eastern Veterinary",
/*0*/client.Title,
/*1*/client.LastName,
/*2*/client.Pet.Animal,
/*3*/client.Pet.Name,
/*4*/client.Pet.Gender == Gender.Male ? "his" : "her",
/*5*/client.Pet.Schedule[0]
);
Mettre à jour
Il me semble que l'exemple que j'ai donné est un peu déroutant, car il semble que j'ai utilisé à la fois la concaténation et string.Format
ici. Et oui, logiquement et lexiquement, c'est ce que j'ai fait. Mais les concaténations seront toutes optimisées par le compilateur 1 , car ce sont toutes des chaînes littérales. Donc, au moment de l'exécution, il y aura une seule chaîne. Je suppose donc que je devrais dire que je préfère éviter de nombreuses concaténations au moment de l'exécution .
Bien sûr, la plupart de ce sujet est désormais obsolète, à moins que vous ne soyez toujours bloqué en utilisant C # 5 ou une version antérieure. Maintenant, nous avons des chaînes interpolées , qui, pour la lisibilité, sont bien supérieures à string.Format
, dans presque tous les cas. Ces jours-ci, à moins que je ne concatène une valeur directement au début ou à la fin d'une chaîne littérale, j'utilise presque toujours l'interpolation de chaîne. Aujourd'hui, j'écrirais mon exemple précédent comme ceci:
Console.WriteLine(
$"Dear {client.Title} {client.LastName},\n\n" +
$"Our records indicate that your {client.Pet.Animal}, \"{client.Pet.Name}\", " +
$"is due for {(client.Pet.Gender == Gender.Male ? "his" : "her")} " +
$"{client.Pet.Schedule[0]} shots.\n" +
"Please call our office at 1-900-382-5633 to make an appointment.\n\n" +
"Thank you,\n" +
"Eastern Veterinary"
);
Vous perdez ainsi la concaténation au moment de la compilation. Chaque chaîne interpolée est transformée en un appel string.Format
par le compilateur et leurs résultats sont concaténés au moment de l'exécution. Cela signifie qu'il s'agit d'un sacrifice des performances d'exécution pour la lisibilité. La plupart du temps, c'est un sacrifice qui en vaut la peine, car la pénalité d'exécution est négligeable. Dans le code critique de performances, cependant, vous devrez peut-être profiler différentes solutions.
1
Vous pouvez voir ceci dans la spécification C # :
... les constructions suivantes sont autorisées dans les expressions constantes:
...
- L'opérateur binaire + ... prédéfini ...
Vous pouvez également le vérifier avec un petit code:
const string s =
"This compiles successfully, " +
"and you can see that it will " +
"all be one string (named `s`) " +
"at run time";