Pourquoi la valeur par défaut du type de chaîne est-elle nulle au lieu d'une chaîne vide?

C'est assez ennuyeux de tester toutes mes chaînes nullavant de pouvoir appliquer en toute sécurité des méthodes comme ToUpper(), StartWith()etc ...

Si la valeur par défaut de stringétait la chaîne vide, je n'aurais pas à tester et je la sentirais plus cohérente avec les autres types de valeur comme intou doublepar exemple. De plus, cela Nullable<String>aurait du sens.

Alors pourquoi les concepteurs de C # ont-ils choisi d'utiliser nullcomme valeur par défaut des chaînes?

Remarque: Cela se rapporte à cette question , mais est plus axé sur le pourquoi plutôt que sur ce qu'il faut en faire.

Pourquoi la valeur par défaut du type de chaîne est-elle nulle au lieu d'une chaîne vide?

Car stringest un type de référence et la valeur par défaut pour tous les types de référence est null.

C'est assez ennuyeux de tester toutes mes chaînes pour null avant de pouvoir appliquer en toute sécurité des méthodes comme ToUpper (), StartWith () etc ...

Cela est cohérent avec le comportement des types de référence. Avant d'appeler leurs membres d'instance, il convient de mettre en place une vérification pour une référence nulle.

Si la valeur par défaut de chaîne était la chaîne vide, je n'aurais pas à tester et je la sentirais plus cohérente avec les autres types de valeurs comme int ou double par exemple.

Affecter la valeur par défaut à un type de référence spécifique autre que nullle rendrait incohérent .

De plus, cela Nullable<String>aurait du sens.

Nullable<T>fonctionne avec les types de valeur. Il convient de noter le fait qu'il Nullablen'a pas été introduit sur la plate-forme .NET d' origine, il y aurait donc eu beaucoup de code cassé s'ils avaient modifié cette règle. ( Courtesy @jcolebrand )

Habib a raison - car stringc'est un type de référence.

Mais plus important encore, vous n'avez pas à vérifier nullchaque fois que vous l'utilisez. Vous devriez probablement jeter unArgumentNullException si quelqu'un transmet une nullréférence à votre fonction .

Voici la chose - le framework vous lancerait NullReferenceExceptionde toute façon si vous essayiez d'appeler .ToUpper()une chaîne. N'oubliez pas que ce cas peut toujours se produire même si vous testez vos arguments nullcar toute propriété ou méthode sur les objets passés à votre fonction en tant que paramètres peut être évaluée commenull .

Cela étant dit, la vérification des chaînes vides ou des valeurs nulles est une chose courante à faire, donc elles fournissent String.IsNullOrEmpty()et String.IsNullOrWhiteSpace()à cette fin.

Vous pouvez écrire une méthode d'extension (pour ce qu'elle vaut):

public static string EmptyNull(this string str)
{
    return str ?? "";
}

Maintenant, cela fonctionne en toute sécurité:

string str = null;
string upper = str.EmptyNull().ToUpper();

Vous pouvez également utiliser ce qui suit, à partir de C # 6.0

string myString = null;
string result = myString?.ToUpper();

Le résultat de la chaîne sera nul.

Les chaînes vides et les valeurs nulles sont fondamentalement différentes. Un null est une absence de valeur et une chaîne vide est une valeur qui est vide.

Le langage de programmation faisant des hypothèses sur la "valeur" d'une variable, dans ce cas une chaîne vide, sera aussi efficace que d'initier la chaîne avec toute autre valeur qui ne causera pas de problème de référence nulle.

De plus, si vous passez le handle de cette variable de chaîne à d'autres parties de l'application, ce code n'aura aucun moyen de valider si vous avez intentionnellement passé une valeur vide ou si vous avez oublié de remplir la valeur de cette variable.

Une autre occasion où ce serait un problème est lorsque la chaîne est une valeur de retour d'une fonction. Étant donné que la chaîne est un type de référence et peut techniquement avoir une valeur nulle et vide à la fois, par conséquent, la fonction peut également retourner techniquement un null ou un vide (rien ne l'empêche de le faire). Maintenant, comme il y a 2 notions d '"absence de valeur", c'est-à-dire une chaîne vide et une valeur nulle, tout le code qui consomme cette fonction devra faire 2 vérifications. Un pour vide et l'autre pour null.

En bref, il est toujours bon de n'avoir qu'une seule représentation pour un seul état. Pour une discussion plus large sur les vides et les null, voir les liens ci-dessous.

/software/32578/sql-empty-string-vs-null-value

NULL vs vide en cas de saisie utilisateur

La raison / le problème fondamental est que les concepteurs de la spécification CLS (qui définit comment les langues interagissent avec .net) n'ont pas défini de moyen par lequel les membres de la classe pourraient spécifier qu'ils doivent être appelés directement, plutôt que viacallvirt , sans que l'appelant effectue une vérification de référence nulle; elle n'a pas non plus permis de définir des structures qui ne seraient pas soumises à une boxe "normale".

Si la spécification CLS avait défini un tel moyen, il serait alors possible pour .net de suivre systématiquement l'exemple établi par le Common Object Model (COM), selon lequel une référence de chaîne nulle était considérée sémantiquement équivalente à une chaîne vide, et pour d'autres types de classes immuables définis par l'utilisateur qui sont censés avoir une sémantique de valeurs pour définir également des valeurs par défaut. Essentiellement, ce qui se passerait serait que chaque membre de String, par exemple, Lengthsoit écrit comme quelque chose comme [InvokableOnNull()] int String Length { get { if (this==null) return 0; else return _Length;} }. Cette approche aurait offert une très bonne sémantique pour les choses qui devraient se comporter comme des valeurs, mais en raison des problèmes d'implémentation, elles doivent être stockées sur le tas. La plus grande difficulté avec cette approche est que la sémantique de conversion entre ces types et Objectpourrait devenir un peu trouble.

Une approche alternative aurait été de permettre la définition de types de structure spéciaux qui n'héritent pas Objectmais qui ont à la place des opérations de boxe et de déballage personnalisées (qui se convertissent vers / depuis un autre type de classe). Dans une telle approche, il y aurait un type de classe NullableStringqui se comporte comme une chaîne maintenant, et un type de structure encadré personnalisé String, qui contiendrait un seul champ privé Valuede type String. Tentative de conversion Stringde a NullableStringou Objectretourne Valuesi non-null ou String.Emptysi null. En tentant de transtyper en String, une référence non nulle à une NullableStringinstance stockerait la référence dans Value(peut-être en stockant null si la longueur était nulle); le fait de jeter toute autre référence entraînerait une exception.

Même si les chaînes doivent être stockées sur le tas, il n'y a théoriquement aucune raison pour qu'elles ne se comportent pas comme des types de valeur qui ont une valeur par défaut non nulle. Les avoir stockés comme une structure "normale" qui contenait une référence aurait été efficace pour le code qui les utilisait comme type "chaîne", mais aurait ajouté une couche supplémentaire d'indirection et d'inefficacité lors de la conversion en "objet". Bien que je ne prévois pas .net d'ajouter l'une des fonctionnalités ci-dessus à cette date tardive, les concepteurs de futurs cadres pourraient peut-être envisager de les inclure.

Parce qu'une variable de chaîne est une référence , pas une instance .

L'initialiser à Vide par défaut aurait été possible mais cela aurait introduit beaucoup d'incohérences sur toute la carte.

Pourquoi les concepteurs de C # ont choisi d'utiliser null comme valeur par défaut des chaînes?

Étant donné que les chaînes sont des types de référence , les types de référence sont la valeur par défaut est null. Les variables des types de référence stockent des références aux données réelles.

Utilisons un defaultmot-clé pour ce cas;

string str = default(string); 

strest un string, donc c'est un type de référence , donc la valeur par défaut est null.

int str = (default)(int);

strest un int, c'est donc un type de valeur , donc la valeur par défaut est zero.

Si la valeur par défaut de stringétait la chaîne vide, je n'aurais pas à tester

Faux! La modification de la valeur par défaut ne change pas le fait qu'il s'agit d'un type de référence et que quelqu'un peut toujours définir explicitement la référence comme étant null.

De plus, cela Nullable<String>aurait du sens.

Vrai point. Il serait plus logique de ne pas autoriser nullde types de référence, au lieu d'exiger Nullable<TheRefType>cette fonctionnalité.

Alors pourquoi les concepteurs de C # ont-ils choisi d'utiliser nullcomme valeur par défaut des chaînes?

Cohérence avec d'autres types de référence. Maintenant, pourquoi autoriser nullles types de référence? Probablement pour qu'il ressemble à C, même si c'est une décision de conception discutable dans un langage qui fournit également Nullable.

Peut-être que si vous utilisiez l' ??opérateur lors de l'attribution de votre variable de chaîne, cela pourrait vous aider.

string str = SomeMethodThatReturnsaString() ?? "";
// if SomeMethodThatReturnsaString() returns a null value, "" is assigned to str.

Une chaîne est un objet immuable, ce qui signifie que lorsqu'elle reçoit une valeur, l'ancienne valeur n'est pas effacée de la mémoire, mais reste à l'ancien emplacement et la nouvelle valeur est placée dans un nouvel emplacement. Donc, si la valeur par défaut de String aétait String.Empty, cela gaspillerait laString.Empty bloc en mémoire quand on sa première valeur.

Bien que cela semble minuscule, cela pourrait devenir un problème lors de l'initialisation d'un grand tableau de chaînes avec des valeurs par défaut de String.Empty. Bien sûr, vous pouvez toujours utiliser la StringBuilderclasse mutable si cela devait être un problème.

La chaîne étant un type de référence et la valeur par défaut du type de référence est null.

Peut-être que le stringmot clé vous a dérouté, car il ressemble exactement à toute autre déclaration de type de valeur , mais il s'agit en fait d'un alias System.Stringcomme expliqué dans cette question .
De plus, la couleur bleu foncé dans Visual Studio et la première lettre minuscule peuvent induire en erreur en pensant qu'il s'agit d'un struct.

Les types nullables ne sont entrés qu'en 2.0.

Si des types nullables avaient été créés au début du langage, alors la chaîne aurait été non nullable et la chaîne? aurait été annulable. Mais ils ne pouvaient pas faire cela du à la compatibilité descendante.

Beaucoup de gens parlent de type ref ou non de type ref, mais la chaîne est une classe hors du commun et des solutions auraient été trouvées pour le rendre possible.