743 votes

En C#, dois-je utiliser string.Empty ou String.Empty ou "" pour initialiser une chaîne ?

En C#, je veux initialiser une valeur de chaîne avec une chaîne vide.

Comment dois-je m'y prendre ? Quelle est la bonne méthode, et pourquoi ?

string willi = string.Empty;

o

string willi = String.Empty;

o

string willi = "";

ou quoi ?

7 votes

Voir aussi cette discussion similaire pour java : stackoverflow.com/questions/213985/

0 votes

What's more important, is never to compare a string to Sting.Empty. <br>Bad: if(s == "") <br>Good: if(s.Length == 0)

41 votes

Il vaut mieux utiliser String.IsNullOrEmpty(string myString), n'est-ce pas ?

848voto

Jon Skeet Points 692016

Utilisez ce que vous et votre équipe trouvez le plus lisible.

D'autres réponses ont suggéré qu'une nouvelle chaîne est créée chaque fois que vous utilisez "" . Ce n'est pas vrai - en raison de l'internalisation des chaînes, il sera créé soit une fois par assemblage, soit une fois par AppDomain (ou peut-être une fois pour l'ensemble du processus - je ne suis pas sûr à ce sujet). Cette différence est négligeable - massivement, massivement insignifiante.

Ce que vous trouvez le plus lisible est cependant une autre question. C'est subjectif et cela varie d'une personne à l'autre. Je vous suggère donc de trouver ce que la plupart des membres de votre équipe préfèrent et de vous en tenir à cela par souci de cohérence. Personnellement, je trouve que "" plus facile à lire.

L'argument selon lequel "" y " " sont facilement confondus les uns avec les autres, ça ne me plaît pas vraiment. A moins que vous n'utilisiez une police proportionnelle (et je n'ai pas travaillé avec des polices de caractères de ce type), il n'y a pas de différence entre les deux. tout les développeurs qui le font), il est assez facile de faire la différence.

81 votes

Vos yeux peuvent vous tromper lorsque vous vous attendez à voir "", vous pouvez facilement confondre "" avec "". C'est pourquoi il est plus facile d'éditer un texte écrit par quelqu'un d'autre. Votre cerveau n'a pas d'idées préconçues sur le texte, il est donc plus facile de repérer les anormalités.

133 votes

@tvanfosson : Avez-vous (ou un collègue) été victime de ce bug ? Je me méfie de ce genre d'affirmation sans que cela ait réellement causé des problèmes. J'utilise "" depuis des années sans jamais me tromper...

5 votes

Jon, j'utilise Segoe UI 10 pt dans VS. Magnifique, les onglets s'alignent parfaitement de toute façon, et je peux avoir des lignes beaucoup plus longues de cette façon. Peut-être que je ne suis pas un développeur alors :D

385voto

aBetterGamer Points 3188

Il n'y a vraiment aucune différence du point de vue des performances et du code généré. Dans les tests de performance, ils ont fait des allers-retours entre l'un et l'autre, et seulement pour quelques millisecondes.

En regardant le code en coulisse, on ne voit pas vraiment de différence non plus. La seule différence réside dans l'IL, qui string.Empty utiliser l'opcode ldsfld y "" utilise l'opcode ldstr mais c'est seulement parce que string.Empty est statique, et les deux instructions font la même chose. Si vous regardez l'assemblage qui est produit, il est exactement le même.

Code C#

private void Test1()
{
    string test1 = string.Empty;    
    string test11 = test1;
}

private void Test2()
{
    string test2 = "";    
    string test22 = test2;
}

Code IL

.method private hidebysig instance void 
          Test1() cil managed
{
  // Code size       10 (0xa)
  .maxstack  1
  .locals init ([0] string test1,
                [1] string test11)
  IL_0000:  nop
  IL_0001:  ldsfld     string [mscorlib]System.String::Empty
  IL_0006:  stloc.0
  IL_0007:  ldloc.0
  IL_0008:  stloc.1
  IL_0009:  ret
} // end of method Form1::Test1

.method private hidebysig instance void 
        Test2() cil managed
{
  // Code size       10 (0xa)
  .maxstack  1
  .locals init ([0] string test2,
                [1] string test22)
  IL_0000:  nop
  IL_0001:  ldstr      ""
  IL_0006:  stloc.0
  IL_0007:  ldloc.0
  IL_0008:  stloc.1
  IL_0009:  ret
} // end of method Form1::Test2

Code d'assemblage

        string test1 = string.Empty;
0000003a  mov         eax,dword ptr ds:[022A102Ch] 
0000003f  mov         dword ptr [ebp-40h],eax 

        string test11 = test1;
00000042  mov         eax,dword ptr [ebp-40h] 
00000045  mov         dword ptr [ebp-44h],eax 

        string test2 = "";
0000003a  mov         eax,dword ptr ds:[022A202Ch] 
00000040  mov         dword ptr [ebp-40h],eax 

        string test22 = test2;
00000043  mov         eax,dword ptr [ebp-40h] 
00000046  mov         dword ptr [ebp-44h],eax

14 votes

@PrateekSaluja : Pour voir l'IL, vous pouvez utiliser ildasm.exe, qui est livré avec Visual Studio. Pour voir le diassemblage, utilisez la fenêtre 'Disassembly' dans le menu de débogage lorsque vous atteignez un point d'arrêt (cela fonctionne aussi dans le code de version).

1 votes

Je déteste être sur le point de recommander ce produit... MAIS ... reflector vous permet de choisir votre langue lors du désassemblage de la source et IL est une option ! ILDASM est juste un sentiment daté.... L'équipe des outils MS ne semble pas polir ou sortir les bons outils !

88voto

Konrad Rudolph Points 231505

Le meilleur code est celui qui n'existe pas du tout :

La nature fondamentale du codage est que notre tâche, en tant que programmeurs, est de reconnaître que chaque décision que nous prenons est un compromis. [ ] Commencez par la brièveté. Augmentez les autres dimensions selon les besoins des tests.

Par conséquent, moins de code est un meilleur code : Préférer "" a string.Empty o String.Empty . Ces deux-là sont six fois plus longtemps sans aucun avantage supplémentaire - et certainement pas plus de clarté, puisqu'ils expriment exactement la même information.

2 votes

Mais en C#, nous pouvons simplement dire string.IsNullOrWhitespace(s) :p

33 votes

Je suis d'accord pour dire que le code doit être aussi petit que possible, mais je n'irais pas jusqu'à dire que moins de caractères est toujours un meilleur code. Lorsqu'il s'agit de nommer des variables, par exemple, une quantité raisonnable de caractères donne généralement de meilleurs noms qu'en utilisant simplement i et j.

3 votes

@Markus Cela dépend fortement : pour une variable de boucle représentant un indice, i est mieux qu'un long nom de variable. De manière encore plus générale, des noms de variables plus courts qui transmettent la même information dans la même clarté, sont toujours préférables. C'est juste que pour exprimer les informations nécessaires, il faut besoin de une certaine longueur de caractères, et je ne le nie pas (personne ne le fait).

56voto

Mentoliptus Points 1414

Une différence est que si vous utilisez un switch-case syntaxe, vous ne pouvez pas écrire case string.Empty: parce que ce n'est pas une constante. Vous obtenez une Compilation error : A constant value is expected

Regardez ce lien pour plus d'informations : chaîne-vide-versus-vides-citations

23 votes

El switch La déclaration est un très bon exemple. De même, si vous rendez un paramètre facultatif, comme void MyMethod(string optional = "") { ... } il n'est pas non plus possible d'utiliser string.Empty . Et puis bien sûr, si vous voulez définir une const ou une variable locale, const string myString = ""; encore une fois "" est la seule option. Si seulement string.Empty étaient un champ constant, il n'y aurait pas de différence. Mais ce n'est pas le cas, donc dans certains cas, vous devez utiliser le champ "" . Alors pourquoi ne pas utiliser "" tout le temps ?

5 votes

C'est un argument très fort parce que l'utilisation string.Empty vous empêche d'atteindre cohérence dans votre base de code : vous devez utiliser deux entités différentes pour exprimer la même chose. Et pour ajouter à la liste des choses que vous ne pouvez pas faire : vous ne pouvez pas utiliser string.Empty avec attributs .

2 votes

De très bons points ! Le lien est cassé. Voici une copie du contenu : web.archive.org/web/20131230161806/http://kossovsky.net/

44voto

Jimmy Points 35501

Je préférerais string a String . en choisissant string.Empty sur "" il s'agit d'en choisir un et de s'y tenir. Avantage de l'utilisation string.Empty c'est qu'il est très évident de comprendre ce que vous voulez dire, et que vous ne copiez pas accidentellement des caractères non imprimables tels que "\x003" dans votre "" .

104 votes

Je dirais que si vous copiez accidentellement des caractères non imprimables dans votre code, vous avez de plus gros problèmes que cette question ;)

10 votes

ASCII \003 se trouve être un délimiteur de champ pour les messages B2B avec lesquels j'ai travaillé :)

7 votes

(Je suggère également d'éviter les \x échappatoire, btw - il est trop difficile de repérer la différence entre " \x9Bad Compilateur" et " \x9Good Compilateur" qui ont radicalement résultats différents)

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X