Ao comparar uma variável de string com um literal de string com .equals (), existe uma prática padrão para a ordem dos itens? [fechadas]


11

Há benefícios para cada um e compreendo as diferenças, mas o que é considerado a melhor / prática padrão? E porque?

Por exemplo :

"myString".equals(myStringVar)
  • Evita um NPE em potencial e não requer uma verificação nula. (Coisa boa?)
  • Mais limpo para ler, pois uma verificação nula não é necessária.
  • Se nulo não for um valor esperado, seu programa poderá estar sendo interrompido sem ser mais sábio.

Contudo

myStringVar.equals("myString")
  • Requer uma verificação nula se nulo for um valor esperado. (Coisa boa?)
  • Pode desordenar condicionais compostos com verificações nulas.
  • Permite que o NPE informe se algo quebrou.

Qual variação é considerada o padrão a ser usado para Java e por quê?


2
Se nulo é ou não um valor esperado, a operação "igual" deve ser o local para determinar se isso é problema?
— Matthew Flynn

Eu não acho que é. Mas essa é minha opinião. Eu gostaria de ouvir a lógica dos outros.
— BrandonV

Nos idiomas que usam = e / ou == para atribuições / comparações, normalmente é melhor colocar o que não pode ser alterado à esquerda, para que você não possa fazer uma atribuição acidental quando pretendia fazer uma comparação. Para linguagens que usam métodos em um objeto como .equals, não acho que isso importe.
— GordonM 18/03/16

Respostas:


3

Eu suspeito que isso se origine de uma precaução de segurança usada na programação em C (ou C ++) mais antigo. Em C, você poderia atribuir um valor acidentalmente quando pretender testar a igualdade:

if (x = 3)

Essa condição sempre será verdadeira, uma vez que é atribuída um valor x 3, não testando que x é igual a 3. Para evitar esses erros sutis, os desenvolvedores começaram a reverter a condição:

if (3 = x)

Ele contém o mesmo "bug", mas gera um erro do compilador, portanto é mais seguro.

Os idiomas mais modernos não têm esse problema e podem alertá-lo facilmente quando você tenta fazer esse tipo de coisa. Como tal, não é uma preferência muito pura; escolha uma e use-a de forma consistente.


-1 Este não é o motivo da convenção Java para equals. Diferentemente de C, o problema para Java é que a expressão x.equals(y)lançará um NPE quando xfor nulo. Se você possui um literal String "something"e deseja considerar o caso nullcomo "diferente de", faz sentido escrever "something".equals(y)se não souber se ypode ser nulo. Isso nunca lançará um NPE.
— Andres F.

1
  • O padrão e as boas práticas variam de acordo com a cultura de uma organização para a qual você está trabalhando

  • Nosso padrão no .NET é myStringVar == "myString"simplesmente porque concordamos com isso, ou seja, acreditamos que seja limpo e concsice

Nota: Isso não se aplica ao Java devido à ==comparação das referências em vez dos próprios objetos. Em Java você deve estar usando myStringVar.equals("myString").


3
Pelo menos em Java, não use ==porque ele compara apenas referências de objetos. Dito isto, +1 para a convenção de acordos geralmente define a maneira "correta" de fazer as coisas.
— Michael K

Obrigado por apontar isto! Eu atualizei a resposta :)
— CodeART

@ CodeWorks: Acho que você perdeu o argumento de Michael. Além disso, é Java, não JAVA.
— Amara

A pergunta era: "mas o que é considerado melhor / prática padrão? Por quê?" Minha resposta é que as melhores práticas padrão e variam de uma organização para outra. Você discorda disso?
— CodeART

@ CodeWorks: Ninguém poderia discordar disso, CodeWorks. Mas todos podem concordar que myStringVar == "myString"é uma péssima idéia sobre Java (a menos que você tenha certeza absoluta de que myStringVarestá internado).
— Amara

0

Acho que você está certo, pois depende da semântica de nulidade da variável. Se você não espera que ele seja nulo e não precisa verificar e manipulá-lo, o primeiro formulário é mais limpo.

Dito isto, em vez de incorporar a string literal, uma opção melhor provavelmente seria esta:

private final String MY_STRING = "myString";
if(MY_STRING).equals(myStringVar);

Especialmente se houver potencial para usar a string em mais de um local.


2
-1: não é realmente melhor; acrescenta a desordem com o valor geralmente insignificante
— amara

@sparkleshy - Discordo, você realmente não quer literais de strings espalhados por sua lógica de código. Como mencionado na resposta original, se a string literal for usada em mais de um local, eu diria que definitivamente as refatoraria.
— Benjamin Wootton

Para dizer isso, você precisa dissimular completamente o python, já que, no python, os identificadores são basicamente literais de string. E acho que todos temos que concordar que python é uma linguagem fina.
— amara
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.