¿Por qué el valor predeterminado del tipo de cadena es nulo en lugar de una cadena vacía?

Es bastante molesto probar todas mis cadenas nullantes de poder aplicar de forma segura métodos como ToUpper(), StartWith()etc.

Si el valor predeterminado de stringfuera la cadena vacía, no tendría que probar, y sentiría que es más consistente con los otros tipos de valores como into doublepor ejemplo. Además Nullable<String>tendría sentido.

Entonces, ¿por qué los diseñadores de C # eligieron usar nullel valor predeterminado de las cadenas?

Nota: Esto se relaciona con esta pregunta , pero se centra más en el por qué en lugar de qué hacer con él.

¿Por qué el valor predeterminado del tipo de cadena es nulo en lugar de una cadena vacía?

Porque stringes un tipo de referencia y el valor predeterminado para todos los tipos de referencia es null.

Es bastante molesto probar nulos todas mis cadenas antes de poder aplicar de forma segura métodos como ToUpper (), StartWith (), etc.

Eso es consistente con el comportamiento de los tipos de referencia. Antes de invocar a los miembros de su instancia, se debe establecer una marca para una referencia nula.

Si el valor predeterminado de la cadena fuera la cadena vacía, no tendría que probar, y sentiría que es más coherente con los otros tipos de valores como int o double, por ejemplo.

Asignar el valor predeterminado a un tipo de referencia específico que nullno sea inconsistente .

Además Nullable<String>tendría sentido.

Nullable<T>trabaja con los tipos de valor. Cabe destacar el hecho de que Nullableno se introdujo en la plataforma .NET original , por lo que habría habido un montón de código roto si hubieran cambiado esa regla. ( Cortesía de @jcolebrand )

Habib tiene razón, porque stringes un tipo de referencia.

Pero lo más importante, no tiene que verificar nullcada vez que lo usa. Sin embargo, probablemente debería arrojar un ArgumentNullExceptionsi alguien pasa su función como nullreferencia.

Aquí está la cosa: el marco arrojaría un NullReferenceExceptionpara usted de todos modos si intenta llamar .ToUpper()a una cadena. Recuerde que este caso aún puede ocurrir incluso si prueba sus argumentos nullya que cualquier propiedad o método en los objetos pasados ​​a su función como parámetros pueden evaluar null.

Dicho esto, la verificación de cadenas vacías o nulos es algo común, por lo que proporcionan String.IsNullOrEmpty()y String.IsNullOrWhiteSpace()para este propósito.

Podría escribir un método de extensión (para lo que vale):

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

Ahora esto funciona de manera segura:

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

También puede usar lo siguiente, a partir de C # 6.0

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

El resultado de la cadena será nulo.

Las cadenas vacías y los valores nulos son fundamentalmente diferentes. Un valor nulo es la ausencia de un valor y una cadena vacía es un valor que está vacío.

El lenguaje de programación que hace suposiciones sobre el "valor" de una variable, en este caso una cadena vacía, será tan bueno como iniciar la cadena con cualquier otro valor que no cause un problema de referencia nulo.

Además, si pasa el identificador a esa variable de cadena a otras partes de la aplicación, entonces ese código no tendrá formas de validar si ha pasado intencionalmente un valor en blanco o si ha olvidado completar el valor de esa variable.

Otra ocasión en la que esto sería un problema es cuando la cadena es un valor de retorno de alguna función. Como string es un tipo de referencia y técnicamente puede tener un valor como nulo y vacío, por lo tanto, la función también puede devolver técnicamente un valor nulo o vacío (no hay nada que lo detenga). Ahora, dado que hay 2 nociones de la "ausencia de un valor", es decir, una cadena vacía y un valor nulo, todo el código que consume esta función tendrá que hacer 2 comprobaciones. Uno para vacío y otro para nulo.

En resumen, siempre es bueno tener solo 1 representación para un solo estado. Para una discusión más amplia sobre vacíos y nulos, vea los enlaces a continuación.

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

NULL vs Empty cuando se trata de la entrada del usuario

La razón / problema fundamental es que los diseñadores de la especificación CLS (que define cómo interactúan los lenguajes con .net) no definieron un medio por el cual los miembros de la clase pudieran especificar que deben ser llamados directamente, en lugar de vía callvirt, sin que la persona que realiza la llamada realice un verificación de referencia nula; Tampoco proporcionó un significado de estructuras definitorias que no estarían sujetas al boxeo "normal".

Si la especificación CLS hubiera definido dicho medio, entonces sería posible que .net siguiera consistentemente el liderazgo establecido por el Modelo de Objeto Común (COM), bajo el cual una referencia de cadena nula se consideraba semánticamente equivalente a una cadena vacía, y para otros tipos de clase inmutables definidos por el usuario que se supone que tienen una semántica de valores para definir igualmente los valores predeterminados. Esencialmente, lo que sucedería sería que cada miembro de String, por ejemplo, Lengthse escribiera como algo así [InvokableOnNull()] int String Length { get { if (this==null) return 0; else return _Length;} }. Este enfoque habría ofrecido una semántica muy buena para cosas que deberían comportarse como valores, pero debido a problemas de implementación deben almacenarse en el montón. La mayor dificultad con este enfoque es que la semántica de conversión entre estos tipos y Objectpodría volverse un poco turbia.

Un enfoque alternativo habría sido permitir la definición de tipos de estructura especiales que no heredaran, Objectsino que tuvieran operaciones de boxeo y desempaquetado personalizadas (que se convertirían a / de algún otro tipo de clase). Bajo tal enfoque, habría un tipo de clase NullableStringque se comporta como lo hace una cadena ahora, y un tipo de estructura en caja personalizada String, que contendría un único campo Valuede tipo privado String. El intento de convertir un Stringa NullableStringo Objectvolvería Valuesi no nulo, o String.Emptysi es nulo. Intentando convertir String, una referencia no nula a una NullableStringinstancia almacenaría la referencia en Value(tal vez almacenando nulo si la longitud fuera cero); emitir cualquier otra referencia arrojaría una excepción.

Aunque las cadenas deben almacenarse en el montón, conceptualmente no hay ninguna razón por la que no deberían comportarse como tipos de valor que tienen un valor predeterminado no nulo. Tenerlos almacenados como una estructura "normal" que contenía una referencia habría sido eficiente para el código que los usó como tipo "cadena", pero habría agregado una capa adicional de indirección e ineficiencia al convertir a "objeto". Si bien no preveo que .net agregue ninguna de las características anteriores en esta fecha tardía, quizás los diseñadores de futuros marcos podrían considerar incluirlas.

Porque una variable de cadena es una referencia , no una instancia .

Inicializarlo a Vacío por defecto habría sido posible, pero habría introducido muchas inconsistencias en todo el tablero.

¿Por qué los diseñadores de C # optaron por usar nulo como el valor predeterminado de las cadenas?

Como las cadenas son tipos de referencia , los tipos de referencia tienen un valor predeterminado null. Las variables de los tipos de referencia almacenan referencias a los datos reales.

Usemos la defaultpalabra clave para este caso;

string str = default(string); 

stres un string, entonces es un tipo de referencia , entonces el valor predeterminado es null.

int str = (default)(int);

stres un int, entonces es un tipo de valor , entonces el valor predeterminado es zero.

Si el valor predeterminado de stringfuera la cadena vacía, no tendría que probar

¡Incorrecto! Cambiar el valor predeterminado no cambia el hecho de que es un tipo de referencia y alguien aún puede establecer explícitamente que la referencia sea null.

Además Nullable<String>tendría sentido.

Punto verdadero Tendría más sentido no permitir nullningún tipo de referencia, sino que requeriría Nullable<TheRefType>esa característica.

Entonces, ¿por qué los diseñadores de C # eligieron usar nullel valor predeterminado de las cadenas?

Consistencia con otros tipos de referencia. Ahora, ¿por qué permitir los nulltipos de referencia? Probablemente para que se sienta como C, a pesar de que esta es una decisión de diseño cuestionable en un lenguaje que también proporciona Nullable.

Quizás si usa el ??operador al asignar su variable de cadena, podría ayudarlo.

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

Una cadena es un objeto inmutable, lo que significa que cuando se le da un valor, el valor anterior no se borra de la memoria, sino que permanece en la ubicación anterior, y el nuevo valor se coloca en una nueva ubicación. Entonces, si el valor predeterminado de String afue String.Empty, desperdiciaría el String.Emptybloque en la memoria cuando se le dio su primer valor.

Aunque parece minúsculo, podría convertirse en un problema al inicializar una gran variedad de cadenas con valores predeterminados de String.Empty. Por supuesto, siempre podría usar la StringBuilderclase mutable si esto fuera un problema.

Como la cadena es un tipo de referencia y el valor predeterminado para el tipo de referencia es nulo.

Tal vez la stringpalabra clave lo confundió, ya que se ve exactamente como cualquier otra declaración de tipo de valor , pero en realidad es un alias System.Stringcomo se explica en esta pregunta .
Además, el color azul oscuro en Visual Studio y la primera letra minúscula pueden inducir a error al pensar que es un struct.

Los tipos anulables no llegaron hasta 2.0.

Si los tipos anulables se hubieran hecho al comienzo del lenguaje, entonces string no hubiera sido anulable y string? habría sido anulable. Pero no pudieron hacer esto du a la compatibilidad con versiones anteriores.

Mucha gente habla de ref-type o no ref type, pero string es una clase fuera de lo común y se habrían encontrado soluciones para hacerlo posible.