En C #, je veux initialiser une valeur de chaîne avec une chaîne vide.
Comment dois-je procéder? Quelle est la bonne façon et pourquoi?
string willi = string.Empty;
ou
string willi = String.Empty;
ou
string willi = "";
ou quoi?
En C #, je veux initialiser une valeur de chaîne avec une chaîne vide.
Comment dois-je procéder? Quelle est la bonne façon et pourquoi?
string willi = string.Empty;
ou
string willi = String.Empty;
ou
string willi = "";
ou quoi?
Réponses:
Utilisez tout ce que vous et votre équipe trouvez le plus lisible.
D'autres réponses suggèrent qu'une nouvelle chaîne est créée à chaque utilisation ""
. Ce n'est pas vrai - en raison de l'internement de chaînes, il sera créé une fois par assembly ou une fois par AppDomain (ou peut-être une fois pour l'ensemble du processus - pas sûr sur ce front). Cette différence est négligeable - massivement, massivement insignifiante.
Ce que vous trouvez plus lisible est cependant différent. C'est subjectif et variera d'une personne à l'autre - je vous suggère donc de découvrir ce que la plupart des gens de votre équipe aiment, et tous y aller pour la cohérence. Personnellement, je trouve ""
plus facile à lire.
L'argument selon lequel ""
et " "
se confondent facilement les uns avec les autres ne me touche pas vraiment. À moins que vous n'utilisiez une police proportionnelle (et je n'ai pas travaillé avec des développeurs qui le font), il est assez facile de faire la différence.
string.Empty
n'est pas une constante . Cela signifie que dans un certain nombre de cas où une constante de temps de compilation est requise, ce string.Empty
n'est même pas légal. Cela inclut les case ""
blocs dans les switch
instructions, les valeurs par défaut des paramètres facultatifs , les paramètres et les propriétés dans l'application des attributs , et beaucoup d'autres situations (laissées au lecteur). Donc, étant donné que cela string.Empty
n'est pas autorisé dans certaines situations courantes, il est préférable d'utiliser la ""
convention -everywhere.
Il n'y a vraiment aucune différence du point de vue des performances et du code généré. Dans les tests de performances, ils ont fait des allers-retours entre lesquels l'un était plus rapide que l'autre, et uniquement en quelques millisecondes.
En regardant le code des coulisses, vous ne voyez vraiment aucune différence non plus. La seule différence est dans l'IL, qui string.Empty
utilise l'opcode ldsfld
et ""
utilise l'opcode ldstr
, mais c'est uniquement parce qu'il string.Empty
est statique, et les deux instructions font la même chose. Si vous regardez l'assemblage qui est produit, c'est exactement la même chose.
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
Le meilleur code n'est pas du tout un code :
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 avec brièveté. Augmentez les autres dimensions comme requis par les tests.
Par conséquent, moins de code est meilleur code: Je préfère ""
à string.Empty
ou String.Empty
. Ces deux sont six fois plus longtemps sans avantage supplémentaire - certainement pas de clarté supplémentaire, car ils expriment exactement les mêmes informations.
i
c'est mieux qu'un long nom de variable. Des noms de variables encore plus généraux et plus courts qui véhiculent les mêmes informations , avec la même clarté, sont toujours préférables. C'est juste que pour exprimer les informations nécessaires, vous avez besoin d' une certaine longueur de caractère, et je ne le nie pas (personne ne l'est).
Une différence est que si vous utilisez une switch-case
syntaxe, vous ne pouvez pas écrire case string.Empty:
car ce n'est pas une constante. Vous obtenez unCompilation error : A constant value is expected
Regardez ce lien pour plus d'informations: string-empty-versus-empty-quotes
switch
déclaration en est un très bon exemple. De plus, si vous créez un paramètre facultatif, comme void MyMethod(string optional = "") { ... }
, il n'est également pas possible de l'utiliser string.Empty
. Et puis bien sûr si vous voulez définir un const
champ ou une variable locale, const string myString = "";
la encore ""
est la seule option. Si seulement string.Empty
était 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 ""
. Alors pourquoi ne pas utiliser ""
tout le temps?
string.Empty
vous empêche d'atteindre la 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 des attributs .
Je préfère string
à String
. le choix de string.Empty
plus ""
est une question de choisir un et s'y tenir. L'avantage de l'utilisation string.Empty
est qu'il est très évident de ce que vous voulez dire, et vous ne copiez pas accidentellement des caractères non imprimables comme "\x003"
dans votre ""
.
""
est dangereux lorsque le copier / coller est nul, je prétends, car vous ne copiez / collez jamais la chaîne vide. Pour les autres cordes, c'est toujours quelque chose à garder à l'esprit, bien sûr.
Je n'allais pas sonner, mais je vois des informations erronées être jetées ici.
Personnellement, je préfère string.Empty
. C'est une préférence personnelle, et je me plie à la volonté de l'équipe avec laquelle je travaille au cas par cas.
Comme certains l'ont mentionné, il n'y a aucune différence entre string.Empty
et String.Empty
.
De plus, et c'est un fait peu connu, l'utilisation de "" est parfaitement acceptable. Chaque instance de "" créera, dans d'autres environnements, un objet. Cependant, .NET intègre ses chaînes, de sorte que les instances futures extrairont la même chaîne immuable du pool de stagiaires et tout impact sur les performances sera négligeable. Source: Brad Abrams .
Personnellement, je préfère "" à moins qu'il n'y ait une bonne raison à quelque chose de plus complexe.
String.Empty
et string.Empty
sont équivalents. String
est le nom de la classe BCL; string
est son alias C # (ou raccourci, si vous voulez). Identique à Int32
et int
. Voir les documents pour plus d'exemples.
En ce ""
qui me concerne, je ne suis pas vraiment sûr.
Personnellement, j'utilise toujours string.Empty
.
Presque tous les développeurs savent ce que "" signifie. Je String.Empty personnellement rencontré la première fois et a dû passer un peu de temps à chercher Google pour savoir si vraiment ils sont exactement la même chose.
string.Empty
? Saviez-vous quelle ""
était la première fois que vous l'avez vue?
Ce sujet est assez ancien et long, alors excusez-moi si ce comportement a été mentionné ailleurs. (Et pointez-moi vers la réponse qui couvre cela)
J'ai trouvé une différence dans le comportement du compilateur si vous utilisez string.Empty
ou des guillemets doubles. La différence apparaît si vous n'utilisez pas la variable chaîne initialisée avec string.Empty ou avec des guillemets doubles.
En cas d'initialisation avec string.Empty
l'avertissement du compilateur
CS0219 - The variable 'x' is assigned but its value is never used
n'est jamais émis alors qu'en cas d'initialisation avec des guillemets doubles, vous obtenez le message attendu.
Ce comportement est expliqué dans l'article Connect sur ce lien: https://connect.microsoft.com/VisualStudio/feedback/details/799810/c-warning-cs0219-not-reported-when-assign-non-constant-value
Fondamentalement, si je comprends bien, ils veulent permettre à un programmeur de définir une variable avec la valeur de retour d'une fonction à des fins de débogage sans le déranger avec un message d'avertissement et ils ont donc limité l'avertissement uniquement en cas d'affectations et de chaînes coûteuses. Vide n'est pas une constante mais un champ.
var unused = "literal";
peut être complètement optimisée (supprimée) par le compilateur. Cela ne peut avoir aucun effet secondaire. En revanche, var unused = MyClass.Member;
ne peut pas être entièrement supprimé. En effet, la lecture Member
pourrait avoir des effets secondaires. S'il Member
s'agit d'une propriété statique avec un get
accesseur, il est clair que l'appel au getter doit être conservé. Mais même s'il Member
s'agit d'un champ statique, il peut y avoir l'effet secondaire que le constructeur statique peut exécuter. Bien sûr, ce serait un mauvais style de codage de l'avoir de cette façon. Mais vous avez besoin d'un mannequin pour lire Member
.
J'ai effectué ce test très simple en utilisant la méthode suivante dans une application console:
private static void CompareStringConstants()
{
string str1 = "";
string str2 = string.Empty;
string str3 = String.Empty;
Console.WriteLine(object.ReferenceEquals(str1, str2)); //prints True
Console.WriteLine(object.ReferenceEquals(str2, str3)); //prints True
}
Cela suggère clairement que les trois variables à savoir str1
, str2
et str3
bien qu'elles soient initialisées en utilisant une syntaxe différente, pointent vers la même chaîne (de longueur nulle) en mémoire. J'ai effectué ce test dans l'application console .NET 4.5. Donc, en interne, ils n'ont aucune différence et tout se résume à la commodité de celui que vous souhaitez utiliser en tant que programmeur. Ce comportement de classe de chaîne est appelé internement de chaîne dans .NET. Eric Lippert a un très joli blog ici décrivant ce concept.
Tout ce qui précède.
Il y a beaucoup, beaucoup de meilleures choses à pontifier. Comme la couleur de l'écorce qui convient le mieux à un arbre, je pense que le brun est vague avec des nuances de mousse de dulcet.
Je préfère fortement String.Empty, en dehors des autres raisons pour vous assurer que vous savez ce que c'est et que vous n'avez pas accidentellement supprimé le contenu, mais principalement pour l'internationalisation. Si je vois une chaîne entre guillemets, je dois toujours me demander s'il s'agit d'un nouveau code et qu'il doit être placé dans une table de chaînes. Donc, chaque fois que le code est modifié / révisé, vous devez rechercher «quelque chose entre guillemets» et oui, vous pouvez filtrer les chaînes vides, mais je dis aux gens que c'est une bonne pratique de ne jamais mettre de chaînes entre guillemets, sauf si vous savez qu'il ne sera pas localisé .
Personne n'a mentionné que dans VisualStudio String, le code couleur était différent de string. Ce qui est important pour la lisibilité. En outre, les minuscules sont généralement utilisées pour les vars et les types, ce n'est pas un gros problème, mais String.Empty est une constante et non un var ou un type.
string
est synonyme de System.String
type, Ils sont identiques.
Les valeurs sont également identiques: string.Empty == String.Empty == ""
Je n'utiliserais pas la constante de caractère "" dans le code, string.Empty
ou plutôtString.Empty
- plus facile de voir ce que le programmeur voulait dire.
Entre string
et String
j'aime les minuscules string
plus simplement parce que j'ai travaillé avec Delphi pendant de nombreuses années et que le style Delphi est en minuscules string
.
Donc, si j'étais ton patron, tu écrirais string.Empty
Je serais en faveur de string.Empty
plus String.Empty
parce que vous pouvez l' utiliser sans avoir besoin d'inclure un using System;
dans votre dossier.
Quant au picking ""
over string.Empty
, c'est une préférence personnelle et doit être décidé par votre équipe.
string.Empty
constant sans importer d' using System
espace de noms - Les mots clés en C # sont simplement convertis en leur nom complet qui inclut également l'espace de noms avant d'être écrits en MSIL dans la sortie * .dll ou *. fichier exe. Obtient donc efficacement string.Empty
écrit comme System.String.Empty
dans le MSIL par le compilateur. Et comme vous le savez peut-être déjà, si vous mentionnez un nom de type complet, vous pouvez ignorer l'importation des espaces de noms en haut de votre fichier de code.
Je ne fais aucune différence. Le dernier est le plus rapide à taper :)
Ce n'est pas grave - c'est exactement la même chose. Cependant, l'essentiel est que vous devez être cohérent
ps je lutte avec ce genre de "ce qui est la bonne chose" tout le temps.
C'est totalement une préférence de style de code, faites à la façon dont .NET gère les chaînes. Cependant, voici mes opinions :)
J'utilise toujours les noms de type BCL lors de l'accès aux méthodes, propriétés et champs statiques: String.Empty
ou Int32.TryParse(...)
ouDouble.Epsilon
J'utilise toujours les mots clés C # lors de la déclaration de nouvelles instances: int i = 0;
oustring foo = "bar";
J'utilise rarement des littéraux de chaîne non déclarés car j'aime pouvoir scanner le code pour les combiner en constantes nommées réutilisables. Le compilateur remplace de toute façon les constantes par les littéraux, donc c'est plus un moyen d'éviter les chaînes / nombres magiques et de leur donner un peu plus de sens avec un nom. De plus, la modification des valeurs est plus facile.
L'un ou l'autre des deux premiers serait acceptable pour moi. J'éviterais le dernier car il est relativement facile d'introduire un bug en mettant un espace entre les guillemets. Ce bug particulier serait difficile à trouver par observation. En supposant qu'aucune faute de frappe, tous sont sémantiquement équivalents.
[ÉDITER]
En outre, vous voudrez peut-être toujours utiliser l'un string
ou l' autre String
pour des raisons de cohérence, mais c'est juste moi.
J'ai personnellement été témoin "" de problèmes (mineurs) à deux reprises. Une fois était due à une erreur d'un développeur junior nouveau dans la programmation en équipe, et l'autre était une simple faute de frappe, mais le fait est d'utiliser de la chaîne. Vide aurait évité les deux problèmes.
Oui, c'est vraiment un appel au jugement, mais quand un langage vous donne plusieurs façons de faire les choses, j'ai tendance à pencher vers celui qui a le plus de surveillance du compilateur et la plus forte application au moment de la compilation. Ce n'est pas "". Il s'agit d'exprimer une intention spécifique.
Si vous tapez string.EMpty ou Strng.Empty, le compilateur vous permet de savoir que vous l'avez mal fait. Immédiatement. Il ne compilera tout simplement pas. En tant que développeur, vous citez des intention que le compilateur (ou un autre développeur) ne puisse en aucun cas mal interpréter, et lorsque vous le faites mal, vous ne pouvez pas créer de bogue.
Si vous tapez "" quand vous voulez dire "" ou vice-versa, le compilateur fait ce que vous lui avez dit de faire. Un autre développeur peut ou non être capable de glaner votre intention spécifique. Bug créé.
Bien avant string.Empty était une chose que j'avais utilisé une bibliothèque standard qui définissait la constante EMPTY_STRING. Nous utilisons toujours cette constante dans les instructions case où string.Empty n'est pas autorisé.
Dans la mesure du possible, mettez le compilateur à votre service et éliminez la possibilité d'erreur humaine, aussi petite soit-elle. OMI, cela l'emporte sur la "lisibilité" comme d'autres l'ont cité.
Spécificité et temps de compilation. C'est ce qui est pour le dîner.
Le compilateur devrait les rendre identiques à long terme. Choisissez une norme pour que votre code soit facile à lire et respectez-la.
Je regardais juste du code et cette question m'est venue à l'esprit que j'avais lue quelque temps auparavant. C'est certainement une question de lisibilité.
Considérez le code C # suivant ...
(customer == null) ? "" : customer.Name
contre
(customer == null) ? string.empty : customer.Name
Personnellement, je trouve ce dernier moins ambigu et plus facile à lire.
Comme l'ont souligné d'autres, les différences réelles sont négligeables.
Bien que la différence soit très, TRÈS petite, la différence existe toujours.
1) "" crée un objet alors que String.Empty ne le fait pas. Mais cet objet sera créé une fois et sera référencé à partir du pool de chaînes plus tard si vous avez un autre "" dans le code.
2) La chaîne et la chaîne sont identiques, mais je recommanderais d'utiliser String.Empty (ainsi que String.Format, String.Copy etc.) car la notation par points indique la classe, pas l'opérateur, et la classe commençant par une lettre majuscule est conforme à Normes de codage C #.
Sur http://blogs.msdn.com/b/brada/archive/2003/04/22/49997.aspx :
Comme David l'indique, il y a une différence entre
String.Empty
et""
sont assez petits, mais il y a une différence.""
crée en fait un objet, il sera probablement retiré du pool de chaînes internes, mais quand même ... alors qu'ilString.Empty
ne crée aucun objet ... donc si vous cherchez vraiment en fin de compte l'efficacité de la mémoire, je suggèreString.Empty
. Cependant, vous devez garder à l'esprit que la différence est si simple que vous ne l'aimerez jamais dans votre code ...
Quant àSystem.String.Empty
oustring.Empty
ouString.Empty
... mon niveau de soin est faible ;-)
La chaîne vide est comme un ensemble vide juste un nom que tout le monde utilise pour appeler ""
. Dans les langues formelles, les chaînes créées à partir d'un alphabet de longueur nulle sont également appelées chaîne vide. L'ensemble et la chaîne ont un symbole spécial pour cela. Chaîne vide: ε et ensemble vide: ∅. Si vous voulez parler de cette chaîne de longueur nulle, vous l'appelerez la chaîne vide afin que tout le monde sache exactement à quoi vous faites référence. Maintenant, si vous la nommez la chaîne vide pourquoi ne pas l'utiliser string.Empty
dans le code, cela montre que l'intention est explicite. L'inconvénient est que ce n'est pas une constante et donc pas disponible partout, comme dans les attributs. (Ce n'est pas une constante pour certaines raisons techniques, voir la source de référence.)
Je préfère ""
car il est plus court et String.Empty
résout un problème qui n'existe pas.