C # String.IsNullOrEmpty: bom ou ruim?

StackOverflow https://stackoverflow.com/questions/1690974

  •  18-09-2019
  •  | 
  •  

Pergunta

Depois de um incidente no trabalho onde eu mal utilizado String.IsNullOrEmpty com uma variável de sessão, um companheiro colega meu agora se recusa a aceitar o meu uso de String.IsNullOrEmpty. Depois de alguma pesquisa, aparentemente, há um bug coletados para IsNullOrEmpty no MSDN ( link ) (nota lida na parte inferior):

A partir de 04 de abril de 2006, há um bug (Possível no JIT) que torna este método falhar quando otimizações são ligadas. Ele é conhecido por afetar tanto C # e VB.

Mais informação pode ser encontrada aqui ( ligação ) . Microsoft o bug é 'supostamente' fixa pós-Orcas, mas infelizmente meu empregador ainda usa VS2005. Mas se o problema é corrigido no 2008+ que assim seja. Isso é apenas bom para mim.

Enquanto a recusa do meu colega do meu código com IsNullOrEmpty para mim é ignorância cega (IMO), ele certamente não pode me dizer por que não para usá-lo diferente do uso indevido com a variável de sessão. Eu usei IsNullOrEmpty todo o nosso código sem problema algum. Pessoalmente, acho que é muito mais legível, além de fazer duas coisas em um comunicado.

Depois de googling para opiniões sobre o assunto, eu encontrei sites que levam o pros / con postura. Aqui estão alguns dos sites que eu li sobre isso:

https://blog.rthand.com/post/2006 /06/22/1063.aspx

http://www.omegacoder.com/?p=105

Um site ( http://dotnetperls.com/isnullorempty ) resume o método (IMHO) pretty bem:

Aqui nós olhamos que IsNullOrEmpty método do tipo string, que nos fornece uma boa e relativamente método eficiente de verificar se um string é OK para salvar ou uso. Contudo, para o desempenho, pode ser melhor usar cheques nulos manuais. strings vazias também pode ser testado em outras maneiras, e minha pesquisa aqui mostra que a verificação comprimento é mais rápido.

Assumindo a correção de bug está no lugar (e funcionando corretamente) no VS2008 / 2010 / etc., Há alguma razão não usar String.IsNullOrEmpty com VS2005 e além? Sei que isso pode parecer um pouco exagerado ao longo de um método pouco boba, mas eu gostaria de saber se há algo mais por trás das cenas acontecendo e se alguém tem explicações alternativas.

Foi útil?

Solução

Este problema foi corrigido no .NET 2.0 SP1. Não há nenhuma razão para evitar seu uso agora.

Se você estiver usando .NET 2, você deve ter o SP1 para muitas outras razões de qualquer maneira -. Não vejo nenhuma razão para evitar este para um bug que já não existe

Outras dicas

Eu ouvi sobre esse erro antes, e pelo que eu pude perceber isso nunca ocorre em qualquer código real, somente no código como o exemplo que realmente não fazer nada. Além disso, o erro não é com o próprio método IsNullOrEmpty, por isso iria ocorrer independentemente de como você verificar a string.

Se o método faz exatamente o que você quer fazer, você deve usá-lo. No entanto, você não deve usá-lo em cada situação para verificar se há uma cadeia vazia. Às vezes você só quer verificar se a cadeia está vazia e não se é nulo.

Se a variável de cadeia é nula, isso irá simplesmente ignorar o bloco de código: 

 if (!String.IsNullOrEmpty(str)) { ... }

Se a variável de cadeia é nula, isso irá causar uma exceção: 

 if (str.Length > 0) { ... }

Se a variável não é suposto ser nulo, você provavelmente vai querer a exceção em vez do código tratar o valor nulo como uma cadeia vazia. Se algo está errado você quiser pegá-lo o mais cedo possível, porque vai ser mais difícil de rastrear as costas problema para a origem quanto mais tempo a exceção é da causa.

Você poderia escrever um teste de unidade que passa uma string vazia e uma que passa uma seqüência nula para testar este material, e executá-lo no VS2005 e depois em 2008 e ver o que aconteceu

Nesse relatório de bug no link que você incluí-lo declara:

Este bug foi corrigido no Microsoft .NET Framework 2.0 Service Pack 1 (SP1).

Desde que o caso não deve importa se você estiver usando o VS 2005, desde que você tem o SP1 para .NET 2 instalado.

Quanto se deve ou não usá-lo, confira este mensagem por CodingHorror .

Nós usamos um método de extensão para string.IsNullOrEmpty: 

public static bool IsNullOrEmpty(this string target)
{
  return string.IsNullOrEmpty(target);
}

Usando essa abordagem, mesmo que fosse à falência em alguma versão anterior, uma correção de bug é apenas uma linha de código.

E o utilitário adicional de ser capaz de usar o método em uma instância de cadeia que pode ser nulo: 

string myString = null;
if (myString.IsNullOrEmpty())
{
  // Still works
}

Eu tenho quase certeza que foi corrigido no SP1, mas de qualquer maneira você pode criar seu próprio nulo ou método vazio:)

Tal como acontece com qualquer linguagem ou parte dele, é saber tudo sobre as vantagens / desvantagens e fazer uma decisão educada com base nessa informação. IMHO.

Ao implementar verificação argumento em APIs, eu costumo verificar para cada condição separadamente e jogar diferentes exceções: ArgumentNullException para uma referência nula ou, dependendo das especificações da API, ArgumentException para uma cadeia vazia. Nesse caso, utilizando String.IsNullOrEmpty não permitem distinguir entre estas duas condições de erro separadas. 

if (str == null)
{
    throw new ArgumentNullException("str");
}
if (str == string.Empty)
{
    throw new ArgumentException("The string cannot be empty.", "str");
}

Se ele está quebrado em sua versão, então é trivial apenas para ter um método estático que irá fazer a verificação, então faça: 

public static bool isNull(String s) {
  return s == null || s.trim().length == 0;
}

Nenhum ponto de entrar em uma grande questão sobre algo que deve ser relativamente fácil de corrigir.

Você não precisa mudá-lo em todos os lugares, embora você pode fazer uma substituição global de um método estático com outro.

Eu me pergunto por que as pessoas usam string.Empty, não é uma coisa boa porque é uma string inicializado e este conceito só existe na Net quadro em todos os lugares este é uma cadeia válida com len de 0 (servidores db deixar bem claro destinction entre este e vai reclamar se você tiver a verificação lógica para nulo, mas você começa e string vazia). Eu acho que string.IsNullOrEmpty é um dos top 5 piores práticas / funções que eu já vi, porque de alguma forma ele incentiva / faz com que pareça pessoas ok para o init suas cordas e pode ser tratada como nulo. Esta função nunca deveria ter sido adicionado e eu acho que os caras Net deve tentar eliminá-los :) Quem precisa e string vazia de qualquer maneira? Eu nunca usei isso a menos que eu tinha que por causa de projetos existentes usou

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top