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 ?
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 ?
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.
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.
@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...
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
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.
private void Test1()
{
string test1 = string.Empty;
string test11 = test1;
}
private void Test2()
{
string test2 = "";
string test22 = test2;
}
.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
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
@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).
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.
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.
@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).
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
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 ?
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 .
De très bons points ! Le lien est cassé. Voici une copie du contenu : web.archive.org/web/20131230161806/http://kossovsky.net/
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 ""
.
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 ;)
ASCII \003 se trouve être un délimiteur de champ pour les messages B2B avec lesquels j'ai travaillé :)
(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 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.
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 ?
3 votes
J'utilise [string.IsNullOrWhiteSpace(stringvalue)] ... cela fonctionne en .Net 4.0. Pour initialiser, j'utilise simplement : [var text = "" ;] Simple, lisible et qui prend le moins de temps à taper :)
66 votes
Ce qui est plus important, c'est le nom hilarant de votre variable.
5 votes
Ce qui m'intéresse, c'est de savoir pourquoi il existe une propriété vide. C'est bien et tout, mais ce n'est pas une nécessité absolue.
0 votes
Duplicata possible de Quelle est la différence entre String.Empty et "" (chaîne vide) ?
0 votes
Là était une différence stackoverflow.c
2 votes
@ZombieSheep Vous ne pouvez pas utiliser IsNullOrEmpty pour définir la valeur d'une variable de type chaîne...
0 votes
De plus, si vous utilisez l'obfuscation de code, string.empty peut être obfusqué alors que "" ne le sera pas. Encore une fois, ce n'est pas une grande différence et cela n'aura pas beaucoup d'importance si vous utilisez une sorte d'obfuscation, mais c'est une différence.