string.Empty vs null. Lequel des deux utilisez-vous ?

Question

Récemment, un collègue de travail m'a dit de ne pas utiliser string.Empty lors de la définition d'une variable de type chaîne, mais utilisez null car il pollue la pile ?

Il dit de ne pas faire

string myString=string.Empty; mais ne string mystring=null;

Est-ce vraiment important ? Je sais que la chaîne est un objet, donc ça a un sens.

Je sais que c'est une question stupide mais quel est votre point de vue ?

Answer 1

null y Empty sont très différents, et je ne suggère pas de passer arbitrairement de l'un à l'autre. Mais aucune n'a de "coût" supplémentaire, puisque Empty est une référence fixe unique (vous pouvez l'utiliser autant de fois que vous le souhaitez).

Il n'y a pas de "pollution" sur la cheminée causée par une ldsfld - cette préoccupation est.... folle. Chargement d'un null est sans doute marginalement moins cher, mais peut provoquer des exceptions de référence nulle si vous ne faites pas attention à la vérification de la valeur.

Personnellement, je n'utilise ni l'un ni l'autre... Si je veux une chaîne vide, j'utilise "" - simple et évident. L'internat signifie ceci également n'a pas de frais généraux par utilisation.

---

Au niveau de l'IL, la différence entre "" et Empty n'est que ldstr et ldsfld - mais les deux donnent la même référence unique de chaîne internée. De plus, dans les versions plus récentes de .NET, le JIT a une interception directe de ceux-ci, ce qui donne la référence de la chaîne vide. sans en faisant une recherche de champ statique. En fait, il n'y a aucune raison de se soucier de l'un ou l'autre de ces éléments, si ce n'est la lisibilité. J'utilise simplement "".

Answer 2

Cela ne "pollue pas la pile", il n'y a pas de raison technique mais il y a une grande différence entre définir une variable comme une référence à un objet (même si c'est une chaîne vide) et null . Ils ne sont pas identiques et doivent être utilisés de manière différente.

null doit être utilisé pour indiquer l'absence de données, string.Empty (ou "" ) pour indiquer la présence de données, en fait du texte vide. Y a-t-il un cas spécifique pour lequel vous n'êtes pas sûr de ce qui est le plus approprié ?

Editer, ajouter des exemples :

• Vous pouvez utiliser string.Empty comme postfixe par défaut pour le nom d'une personne (la plupart des gens n'ont pas de doctorat par exemple)

• Vous pouvez utiliser null pour une option de configuration qui n'a pas été spécifiée dans le fichier de configuration. Dans ce cas, string.Empty serait utilisé si l'option config était présente, mais que la valeur configurée souhaitée était une chaîne vide.

Answer 3

Ils sont différents, comme d'autres ont déjà répondu.

static void Main(string[] args)
{
    string s1 = null;
    string s2 = string.Empty;
    string s3 = "";
    Console.WriteLine(s1 == s2);
    Console.WriteLine(s1 == s3);
    Console.WriteLine(s2 == s3);
}

Résultats :

1. false - puisque null est différent de string.empty
2. false - puisque null est différent de ""
3. true - puisque "" est identique à string.empty

Le problème de la gestion des chaînes de caractères vides par rapport aux chaînes de caractères nulles devient un problème lorsque vous avez besoin de les conserver dans un fichier plat ou de les transférer par des communications. Je pense donc qu'il pourrait être utile pour les autres personnes qui visitent cette page de donner une bonne solution à ce problème particulier.

Dans le but d'enregistrer des chaînes de caractères dans un fichier ou des communications :
vous voudrez probablement convertir la chaîne en octets.
Une bonne pratique que je recommande est d'ajouter 2 segments d'octets d'en-tête à votre chaîne convertie.

segment 1 - méta-info stockée dans un octet et décrivant la longueur du segment suivant.

segment 2 - contient la longueur de la chaîne à sauvegarder.

exemple :
chaîne "abcd" - pour simplifier, je vais la convertir en utilisant l'encodeur ASCII et j'obtiendrai {65,66,67,68}.
calculer le segment 2 donnera 4 - donc 4 octets sont la longueur de la chaîne convertie.
calculer le segment 1 donnera 1 - puisqu'un seul octet a été utilisé pour contenir l'information sur la longueur de la chaîne convertie (qui était de 4, c'est-à-dire que si elle était de 260, j'obtiendrais 2)

La nouvelle bande d'octets sera maintenant {1,4,65,66,67,68} et pourra être enregistrée dans un fichier.

L'avantage par rapport au sujet est que si j'avais une chaîne vide à sauvegarder, j'obtiendrais de la conversion un tableau vide d'octets de longueur 0 et après avoir calculé les segments, j'obtiendrais {1,0} qui peut être sauvegardé et plus tard chargé et réinterprété en une chaîne vide. D'un autre côté, si j'avais une valeur nulle dans ma chaîne, je finirais par avoir juste {0} comme tableau d'octets à sauvegarder et, une fois chargé, il pourrait être interprété comme étant nul.

Il y a d'autres avantages, comme le fait de savoir quelle est la taille à charger ou à accumuler si l'on jagge plusieurs chaînes.

Pour en revenir au sujet, cela polluera en quelque sorte la pile car les mêmes principes décrits sont utilisés par n'importe quel système pour différencier les nuls des vides donc oui string.Empty prend plus de mémoire que null, bien que je n'appellerais pas cela une pollution c'est juste 1 octet de plus.

Answer 4

On a déjà répondu à toutes ces questions, mais null signifie qu'il n'y a pas de valeur, qu'elle n'est pas initialisée. string.Empty signifie "" (une chaîne vide) comme il est indiqué sur MSDN.

Le moyen le plus sûr de vérifier si une chaîne est vide ou nulle est d'utiliser string.IsNullOrEmpty.

Answer 5

Pour info, j'ai trouvé que mélanger "" y String.Empty ne fonctionne pas :

var a = "";
alert("a " + (a == "") + ", " + (a==String.Empty));   //Yields "a true, false"

var b = String.Empty;
alert("b " + (b == "") + ", " + (b == String.Empty)); //Yields "b false, true"

En particulier, si vous utilisez $.trim pour obtenir la valeur d'un champ de saisie DOM vide, puis la comparer à String.Empty vous obtenez false . Je ne sais pas trop pourquoi, mais c'est comme ça. Maintenant, j'utilise simplement "" partout par souci de cohérence.