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


705

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?


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

39
mieux utiliser String.IsNullOrEmpty (string myString) cependant, sûrement?
ZombieSheep

3
J'utilise [string.IsNullOrWhiteSpace (stringvalue)] ... fonctionne dans .Net 4.0. Pour initialiser, j'utilise simplement: [var text = "";] Simple, lisible et prend le moins de temps à taper :)
Jalal El-Shaer

61
Ce qui est plus important, c'est le nom hilarant de votre variable.
Arj

5
La chose qui m'a intéressé, c'est pourquoi y a-t-il même une propriété vide. C'est sympa et tout, mais pas un must nécessaire et complet.
MasterMastic

Réponses:


808

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.


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

125
@tvanfosson: Donc, vous (ou un collègue) avez-vous été mordu par un bug? Je me méfie de ce genre de réclamation sans que cela ait réellement causé de problèmes. J'utilise "" depuis des années sans jamais me tromper ...
Jon Skeet

34
Personnellement, j'ai toujours utilisé String.Vide, j'utilise des majuscules 'S' chaque fois que je veux utiliser une méthode statique sur string, c'est juste une préférence personnelle qui me permet de distinguer un type d'une variable. Mais ce n'est qu'un report de l'utilisation de StringUtils.EMPTY dans commons.lang de java. Un point d'intérêt est que je suis presque aveugle et cela m'aide certainement à la lisibilité.
Brett Ryan

79
Vous m'avez donné l'inspiration pour commencer à développer dans Times New Roman.
Justin Rusbatch

73
Pour une raison obscure, ce string.Emptyn'est pas une constante . Cela signifie que dans un certain nombre de cas où une constante de temps de compilation est requise, ce string.Emptyn'est même pas légal. Cela inclut les case ""blocs dans les switchinstructions, 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.Emptyn'est pas autorisé dans certaines situations courantes, il est préférable d'utiliser la ""convention -everywhere.
Jeppe Stig Nielsen

375

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.Emptyutilise l'opcode ldsfld et ""utilise l'opcode ldstr, mais c'est uniquement parce qu'il string.Emptyest 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.

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 

13
@PrateekSaluja: Pour voir l'IL, vous pouvez utiliser ildasm.exe, fourni avec Visual Studio. Pour voir le démontage, utilisez la fenêtre «Démontage» du menu de débogage lorsque vous atteignez un point d'arrêt (fonctionne également dans le code de version).
Thomas Bratt

1
Je déteste que je suis sur le point de recommander ce produit .. MAIS .. le réflecteur vous permet de choisir votre langue lors du démontage de la source et IL est une option! ILDASM est juste un sentiment désuet ... L'équipe MS Tools ne semble pas polir ou libérer les bons outils!
felickz

80

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.Emptyou 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.


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

31
Je suis d'accord que le code devrait être aussi petit que possible, mais je ne dirais généralement pas 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 que d'utiliser simplement i et j.
Markus Meyer

3
@Markus Cela dépend fortement: pour une variable de boucle représentant un index, 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).
Konrad Rudolph

2
@Konrad: i est un bon nom de variable uniquement si la boucle est petite et qu'elle ne contient aucun autre indice. Mais je suis d'accord que si qc. peut être énoncé plus brièvement en transmettant les mêmes informations, ce qui serait préférable, comme dans la chaîne. Cas vide / "". La chaîne vide n'apporte aucune clarté.
Markus Meyer

Pour moi: string.Empty indique que cette chaîne est et doit être vide à tout moment, tandis que "" indique qu'au moment de l'écriture, cette chaîne peut être vide, mais vous êtes libre de la modifier.
aeroson

54

Une différence est que si vous utilisez une switch-casesyntaxe, 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


22
Cette switchdé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 constchamp 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?
Jeppe Stig Nielsen

5
C'est un argument très fort car l'utilisation string.Emptyvous 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.Emptyavec des attributs .
Pragmateek

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

42

Je préfère stringà String. le choix de string.Emptyplus ""est une question de choisir un et s'y tenir. L'avantage de l'utilisation string.Emptyest 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 "".


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

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

7
(Je suggère également d'éviter l'évasion \ x, btw - il est trop difficile de voir la différence entre "\ x9Bad Compiler" et "\ x9Good Compiler" qui ont des résultats radicalement différents!)
Jon Skeet

Personnellement, je préfère String sur string chaque fois que j'appelle une méthode statique sur String. Je suis presque aveugle cependant et c'est une préférence personnelle que je n'applique à personne.
Brett Ryan

2
@Jimmy Bien sûr, mais nous parlions de la chaîne vide. L'argument qui ""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.
Timo

22

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.Emptyet 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 .


20
Je ne vois pas pourquoi "techniquement" chaque instance de "" créera un objet. Ce n'est pas seulement une chance que des chaînes soient internées - c'est dans la spécification C #.
Jon Skeet

15

Personnellement, je préfère "" à moins qu'il n'y ait une bonne raison à quelque chose de plus complexe.


13

String.Emptyet string.Emptysont équivalents. Stringest le nom de la classe BCL; stringest son alias C # (ou raccourci, si vous voulez). Identique à Int32et 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.


10

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.


3
Il s'agit d'un champ de chaîne public en lecture seule et ses valeurs sont "" ... pourquoi cela changerait-il?
Matthew Whited

5
Vous manquez le point soulevé par @Jason. Comment savez-vous ce que c'est la première fois que vous voyez string.Empty? Saviez-vous quelle ""était la première fois que vous l'avez vue?
David R Tribble,

10

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.Emptyl'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.


1
Je pense que vous êtes le premier à le mentionner. J'ai lu ce Q&R il y a plusieurs mois et je ne me souviens pas de cette différence, ce que j'aurais fait si elle avait été mentionnée.
Palec

2
Intéressant. Notez qu'une déclaration 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 Memberpourrait avoir des effets secondaires. S'il Members'agit d'une propriété statique avec un getaccesseur, il est clair que l'appel au getter doit être conservé. Mais même s'il Members'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.
Jeppe Stig Nielsen

9

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, str2et str3bien 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.


8

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.


7

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é .


7

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.Empty n'est pas une constante: voir stackoverflow.com/questions/507923/… Il s'agit en fait d'une instance de la classe String, par conception. Et la coloration a été mentionnée avant mais un peu cachée: stackoverflow.com/questions/263191/…
Michael

6

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.Emptyou plutôtString.Empty - plus facile de voir ce que le programmeur voulait dire.

Entre stringet Stringj'aime les minuscules stringplus 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


6

Je serais en faveur de string.Emptyplus String.Emptyparce 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.


2
Je suis le seul membre de l'équipe, comment décider? Jeter un dés?
Gqqnbig

1
Pour ceux qui pourraient se demander comment il est possible d'utiliser string.Emptyconstant sans importer d' using Systemespace 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.Emptydans 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.
RBT

5

Je ne fais aucune différence. Le dernier est le plus rapide à taper :)


4

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.


1
Dans le monde moderne, «cohérent» signifie cohérent dans toutes les équipes du monde, ce qui est l'un des objectifs de StackOverflow. Si je peux suggérer, utilisons String.Empty.
Pavel Radzivilovsky

1
Certaines langues n'ont pas de constante Empty, et toutes les langues auxquelles je peux penser autorisent "" une chaîne de longueur nulle. Je vote donc "" pour la cohérence avec les autres langues. :)
TomXP411

4

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.Emptyou 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.


3

J'utilise le troisième, mais des deux autres, le premier semble moins étrange. string est un alias pour String, mais les voir à travers une affectation semble désagréable.


3

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 stringou l' autre Stringpour des raisons de cohérence, mais c'est juste moi.


Je suis d'accord avec cette remarque, mais je vis toujours dangereusement quand je suis paresseux. Quoi qu'il en soit, je ne pense pas avoir l'occasion d'écrire du code qui utilise une chaîne avant de l'assigner en dehors de la déclaration de variable. En fait, c'est ennuyeux pour moi de devoir initialiser mes cordes malgré les risques.
EnocNRoll - AnandaGopal Pardue

3

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.


3

J'utilise "" car il sera coloré en jaune distinctif dans mon code ... pour une raison quelconque, String.Empty est tout blanc dans mon thème Visual Studio Code. Et je crois que c'est ce qui m'importe le plus.


2

Le compilateur devrait les rendre identiques à long terme. Choisissez une norme pour que votre code soit facile à lire et respectez-la.


2

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.


1

Je pense que la seconde est «appropriée», mais pour être honnête, je ne pense pas que cela importera. Le compilateur doit être suffisamment intelligent pour compiler l'un de ceux-ci avec exactement le même bytecode. J'utilise "" moi-même.


1

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 #.


1
string.Empty is "", check the source
dss539

1

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.Emptyet ""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'il String.Emptyne crée aucun objet ... donc si vous cherchez vraiment en fin de compte l'efficacité de la mémoire, je suggère String.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.Emptyou string.Emptyou String.Empty... mon niveau de soin est faible ;-)


1
Ce billet de blog MSDN était en 2003 ... êtes-vous sûr que cela est toujours vrai pour les versions récentes de .NET?!
Carsten Schütte

@ CarstenSchütte: Il me semble qu'une telle fonctionnalité ne devrait pas changer grand-chose ... et si c'était le cas, il y avait du buzz sur Internet à ce sujet.
sergiol

3
@sergiol Si un champ est plus efficace qu'un littéral, il s'agit sans aucun doute d'un bogue de performance. On espère donc que ce sera corrigé maintenant.
Konrad Rudolph

1

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.Emptydans 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.)


0

Je préfère ""car il est plus court et String.Emptyrésout un problème qui n'existe pas.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.