Inicialização de string padrão: NULL ou Empty? [fechadas]

Eu sempre inicializei minhas strings em NULL, pensando que NULL significa a ausência de um valor e "" ou String.Empty é um valor válido. Ultimamente, tenho visto mais exemplos de código em que String.Empty é considerado o valor padrão ou representa nenhum valor. Isso me parece estranho, com os tipos anuláveis ​​recém-adicionados em c #, parece que estamos dando passos para trás com seqüências de caracteres por não usar o NULL para representar 'No Value'.

O que você usa como inicializador padrão e por quê?

Edit: Com base nas respostas, mais meus pensamentos adicionais

1. Evitando o tratamento de erros Se o valor não deve ser nulo, por que foi definido NULLem primeiro lugar? Talvez seja melhor identificar o erro no local em que ocorre, em vez de encobri-lo durante todo o resto da sua base de código?

2. Evitando verificações nulas Se você está cansado de fazer verificações nulas no código, não seria melhor abstrair as verificações nulas? Talvez envolva (ou estenda!) Os métodos de string para torná-los NULLseguros? O que acontece se você usa constantemente String.Emptye um nulo funciona no seu sistema, você começa a adicionar NULLcheques de qualquer maneira?

Não posso deixar de voltar à opinião de que é preguiça. Qualquer DBA lhe daria nove maneiras de bobo se você usasse '' em vez de nullno banco de dados dele. Penso que os mesmos princípios se aplicam à programação e deve haver alguém para dar um tapa na cabeça daqueles que usam String.Emptymais do que NULLpara não representar nenhum valor.

Perguntas relacionadas

• Em C #, devo usar string.Empty ou String.Empty ou “”?
• Qual é a diferença entre String.Empty e "”
• Cadeia de caracteres nula ou vazia para representar nenhum dado na coluna da tabela?

+1 para distinguir entre "vazio" e NULL. Concordo que "vazio" deve significar "válido, mas em branco" e "NULL" devem significar "inválido".

Então, eu responderia sua pergunta assim:

vazio quando desejo um valor padrão válido que possa ou não ser alterado, por exemplo, o nome do meio de um usuário.

NULL quando houver um erro se o código a seguir não definir o valor explicitamente.

De acordo com o MSDN :

Inicializando cadeias com o Emptyvalor em vez de null, você pode reduzir as chances de NullReferenceExceptionocorrência.

Sempre usar IsNullOrEmpty()é uma boa prática, no entanto.

Por que você deseja que sua string seja inicializada? Você não precisa inicializar uma variável quando declara uma e, na IMO, deve fazê-lo somente quando o valor que você está atribuindo for válido no contexto do bloco de código.

Eu vejo muito isso:

string name = null; // or String.Empty
if (condition)
{
  name = "foo";
}
else
{
  name = "bar";
}

return name;

Não inicializar para null seria tão eficaz. Além disso, na maioria das vezes você deseja que um valor seja atribuído. Ao inicializar para nulo, é possível perder os caminhos de código que não atribuem um valor. Igual a:

string name = null; // or String.Empty
if (condition)
{
  name = "foo";
}
else if (othercondition)
{
  name = "bar";
}

return name; //returns null when condition and othercondition are false

Quando você não inicializa para nulo, o compilador gera um erro dizendo que nem todos os caminhos de código atribuem um valor. Claro, este é um exemplo muito simples ...

Matthijs

Para a maioria dos softwares que na verdade não são software de processamento de strings, a lógica do programa não deve depender do conteúdo das variáveis ​​de strings. Sempre que vejo algo assim em um programa:

if (s == "value")

Eu tenho um mau pressentimento. Por que existe uma string literal neste método? O que está definindo s? Ele sabe que a lógica depende do valor da string? Ele sabe que precisa ser minúsculo para funcionar? Devo corrigir isso alterando-o para uso String.Compare? Devo estar criando Enume analisando?

Nessa perspectiva, chega-se a uma filosofia de código bastante simples: você evita examinar o conteúdo de uma string sempre que possível. Comparar uma string com String.Emptyé realmente apenas um caso especial de compará-la a um literal: é algo a ser evitado, a menos que você realmente precise.

Sabendo disso, não pisco quando vejo algo assim em nossa base de código:

string msg = Validate(item);
if (msg != null)
{
   DisplayErrorMessage(msg);
   return;
}

Eu sei que Validateisso nunca voltaria String.Empty, porque escrevemos um código melhor do que isso.

Claro, o resto do mundo não funciona assim. Quando o seu programa está lidando com a entrada do usuário, bancos de dados, arquivos e assim por diante, você deve considerar outras filosofias. Lá, é o trabalho do seu código impor ordem ao caos. Parte dessa ordem é saber quando uma string vazia deve significar String.Emptye quando deve significar null.

(Apenas para ter certeza de que não estava falando sério, procurei em `String.IsNullOrEmpty 'na nossa base de código. Todas as 54 ocorrências estão nos métodos que processam a entrada do usuário, retornam valores dos scripts Python, examinam os valores recuperados de APIs externas etc.)

Este é realmente um buraco na linguagem C #. Não há como definir uma sequência que não possa ser nula. Isso causa problemas tão simples quanto o que você está descrevendo, o que força os programadores a tomar uma decisão que eles não deveriam tomar, pois em muitos casos NULL e String.Empty significam a mesma coisa. Isso, por sua vez, pode forçar outros programadores a lidar com NULL e String.Empty, o que é irritante.

Um problema maior é que os bancos de dados permitem definir campos que são mapeados para uma string C #, mas os campos do banco de dados podem ser definidos como NOT NULL. Portanto, não há como representar com precisão, digamos, um campo varchar (100) NOT NULL no SQL Server usando um tipo C #.

Outros idiomas, como Spec #, permitem isso.

Na minha opinião, a incapacidade do C # de definir uma string que não permita nulo é tão ruim quanto a incapacidade anterior de definir um int que permita nulo.

Para responder completamente à sua pergunta: Eu sempre uso uma string vazia para a inicialização padrão, pois é mais semelhante à forma como os tipos de dados do banco de dados funcionam. (Edit: Esta declaração não era clara. Deveria ler "Eu uso uma string vazia para a inicialização padrão quando NULL é um estado supérfluo, da mesma maneira que configurei uma coluna do banco de dados como NOT NULL se NULL seria um estado supérfluo. Da mesma forma , muitas das minhas colunas do banco de dados são configuradas como NOT NULL, portanto, quando eu as incluir em uma string C #, a string estará vazia ou terá um valor, mas nunca será NULL. Em outras palavras, eu apenas inicializo uma string para NULL. se null tiver um significado distinto do significado de String.Empty, e acho que esse caso é menos que comum (mas as pessoas aqui deram exemplos legítimos deste caso). ")

Depende.

Você precisa saber se o valor está ausente (é possível que ele não seja definido)?

A cadeia vazia é um valor válido para o uso dessa cadeia?

Se você respondeu "sim" a ambos, será melhor usar nulo. Caso contrário, você não pode dizer a diferença entre "sem valor" e "sequência vazia".

Se você não precisa saber se não há valor, a sequência vazia provavelmente é mais segura, pois permite ignorar as verificações nulas onde quer que você a use.

Parece que este é um caso especial do http://en.wikipedia.org/wiki/Null_Object_pattern

Eu o defino como "" ou nulo - sempre verifico usando String.IsNullOrEmpty, portanto, tudo bem.

Mas o nerd interior em mim diz que devo defini-lo como nulo antes de ter um valor adequado para ele ...

Eu sempre declaro string com string.empty;

É possível que essa seja uma técnica de prevenção de erros (recomendável ou não ..)? Como "" ainda é uma sequência, você poderá chamar funções de sequência que resultariam em uma exceção se fosse NULL?

Eu sempre os inicializo como NULL.

Eu sempre uso string.IsNullOrEmpty(someString)para verificar o seu valor.

Simples.

Depende da situação. Na maioria dos casos, uso String.Empty porque não quero fazer verificações nulas toda vez que tento usar uma string. Isso torna o código muito mais simples e é menos provável que você introduza falhas indesejadas de NullReferenceException.

Eu só defino a string como nula quando preciso saber se ela foi configurada ou não e onde uma string vazia é algo válido para defini-la. Na prática, acho essas situações raras.

Uma string vazia é um valor (um pedaço de texto que, aliás, passa a não conter letras). Nulo significa sem valor.

Inicializo variáveis ​​como nulas quando desejo indicar que elas não apontam para ou contêm valores reais - quando a intenção é sem valor.

Reiterando a resposta do Tomalak, lembre-se de que quando você atribui uma variável de cadeia a um valor inicial nulo, sua variável não é mais um objeto de cadeia; mesmo com qualquer objeto em c #. Portanto, se você tentar acessar quaisquer métodos ou propriedades para sua variável e estiver assumindo que é um objeto de sequência, receberá a exceção NullReferenceException.

Nulo deve ser usado apenas nos casos em que um valor é opcional. Se o valor não for opcional (como 'Nome' ou 'Endereço'), o valor nunca deve ser nulo. Isso se aplica a bancos de dados, POCOs e interface do usuário. Nulo significa "esse valor é opcional e está ausente no momento".

Se o seu campo não for opcional, você deve inicializá-lo como a sequência vazia. Inicializá-lo como nulo colocaria seu objeto em um estado inválido (inválido por seu próprio modelo de dados).

Pessoalmente, prefiro que as strings não sejam anuláveis ​​por padrão, mas somente anuláveis ​​se declararmos uma "string?". Embora talvez isso não seja viável ou lógico em um nível mais profundo; não tenho certeza.

Strings não são tipos de valor e nunca serão ;-)

Eu acho que não há razão para não usar nulo para um valor não atribuído (ou neste local em um fluxo de programa que não esteja ocorrendo). Se você deseja distinguir, há == nulo. Se você apenas deseja verificar um determinado valor e não se importa se é nulo ou diferente, String.Equals ("XXX", MyStringVar) funciona perfeitamente.