Pourquoi utiliser string.Empty sur "" lors de l'affectation à un objet string

13

J'ai exécuté StyleCop sur mon code et l'une des recommandations SA1122 est d'utiliser string.Empty plutôt que "" lors de l'attribution d'une chaîne vide à une valeur.

Ma question est de savoir pourquoi cela est considéré comme la meilleure pratique. Ou est-ce considéré comme la meilleure pratique? Je suppose qu'il n'y a pas de différence de compilation entre les deux déclarations, donc je ne peux que penser que c'est une chose de lisibilité?

SO question et réponse

Jon Skeet réponse à la question

c#

— dreza
source

5

Je suis sûr que cela a été demandé et répondu sur Stack Overflow - mais j'ai du mal à le trouver. C'est ""string.Empty

— lié

@ChrisF Ahh, je n'ai pas pensé à regarder le débordement de pile pour ce type de question. J'aurai un coup d'oeil.

— dreza

1

dup de question sur stackoverflow: stackoverflow.com/questions/151472/…

— quentin-starin

@ChrisF - Il a été demandé sur SO. Encore et encore et encore ...

— Oded

1

C'est parti - stackoverflow.com/questions/151472/… - de retour de septembre 2008.

— ChrisF

12

Une raison valable est qu'il indique clairement qu'il ne s'agit pas d'une faute de frappe ou d'un espace réservé, que vous vouliez vraiment utiliser la chaîne vide ici.

Je ne sais pas si c'est considéré comme une "meilleure pratique".

— Philippe
source

7

J'imagine qu'il y a deux raisons, une pour la lisibilité et deux pour une amélioration mineure des performances.

La lisibilité est facile: il est beaucoup plus rapide à repérer string.Emptyque "". La recherche string.Emptysera également généralement plus facile et peut-être plus précise que la recherche du littéral. Cela clarifie également l'intention: vous n'avez pas simplement fait une faute de frappe ou oublié de terminer quelque chose, vous vouliez vraiment une chaîne vide.

La raison de la performance est due à l' internement . Vous voyez, le runtime conserve un tableau des chaînes précédemment utilisées afin qu'il puisse faire rapidement des comparaisons de chaînes sans faire de vérification caractère par caractère. string.Emptyest déjà une référence internée à l' ""endroit où la saisie du littéral peut ne pas vous donner la version interne, provoquant ainsi une légère baisse des performances.

— CodexArcanum
source

7

un nitpick, en tapant le littéral "" vous donnera toujours la même version interne de "", au moins depuis .Net 2 et plus.

— quentin-star du

À droite, l'article interning sur MSDN est un peu difficile à suivre sur ce point. Cela ressemble à "" et à string. Vide devrait tous deux pointer vers la même chaîne internée, mais il semble indiquer des différences entre les versions d'exécution .net. Je pense que tout littéral de chaîne qui apparaît plusieurs fois dans le code sera interné lors de la deuxième utilisation et d'autres utilisations, oui?

— CodexArcanum

4

Je dois également souligner que lorsque je dis léger, je veux dire super petit. "En raison des performances" n'est pas une raison pour passer d'une représentation à l'autre, c'est juste une bonne chose à savoir sur le temps d'exécution.

— CodexArcanum

4

Il convient également de noter que l'aspect performances n'est valable que pour la compilation. Comme les deux se compilent vers le même IL, les performances d'exécution doivent être identiques.

— lzcd

cette amélioration des performances ne serait que lors de la compilation

— ratchet freak

4

string.Empty gagne dans un cas vraiment coin, ce qui peut conduire à un bug magique et vraiment difficile à déboguer:

S'il y a un espace de largeur zéro dans "".

— Yuby
source

0

Selon une documentation que j'ai trouvée, cela a à voir avec ce qui est émis par le compilateur.

Une recherche rapide révèle: http://stylecop.soyuz5.com/SA1122.html

Pourquoi il est classé sous "Règles de lisibilité" avec cette description est déroutant.

— Brian
source