Qual deve ser o sentido de usar uma comparação estrita com essa string específica: 'final'

Question

Qual deve ser o sentido de usar uma comparação estrita com essa string específica: 'final'

#1 resposta do (15 votos)
#2 resposta do (0 votos)

4

Em uma revisão de código que eu estava fazendo para um colega de trabalho, eu disse isso aqui:

if (someValue === 'final'){

Não faz sentido usar uma comparação estrita, porque a única maneira de transmiti-la como verdadeira é com outro valor de string igual a final.

Eu acho que é o suficiente:

if (someValue == 'final'){

Seu argumento é que um objeto poderia ter um método toString que retorna aquela string, mas estritamente não tem o mesmo tipo de dados.

Embora isso seja verdade, como um computador (que não é inteligente como humano), por outro lado, não há sentido, pois no final do caminho a única maneira de passar isso como verdadeiro é com uma string igual a para final. Este foi o código de amostra dele:

Test = function(){}
Test.prototype.toString = function () { return 'final'; }
var disagreeDaniel = new Test();
document.getElementById('foo').innerHTML = (disagreeDaniel == 'final');

Então, meu ponto aqui pessoal, é que eu preciso de você para explicar melhor a ele por que não há sentido da comparação estrita em um estrito fixo como 'final' porque não há como passar isso como positivo com um valor diferente que 'final' (seu exemplo no final retorna a string)

Para mim, a comparação estrita é útil para booleanos, nulos, indefinidos, zero, em que esses podem passar todos como falsos em alguns casos. Eu quero ouvir suas opiniões.

====== Atualização ==========

É fácil identificar que as pessoas não lêem. Minha pergunta foi o sentido de uso === para comparar com 'final'. Eu tenho muitas explicações de coisas que nada para fazer. Para comparar com null, false, zero etc, eu disse que usei === para esses casos, mas não para strings longas. mas as pessoas tentaram me explicar sobre null, false, zero, etc. O veredicto até agora é que não há um argumento SOLID (existem alguns bons, mas não sólidos) que demonstram por que usar === para comparar com 'final' deve ser melhor que usar == (leia novamente, é apenas este caso de uso, estou falando de um caso de uso específico).

Eu também falei com meu colega de trabalho, dei-lhe +1 para o código. Eu não tenho problemas com ===, meu problema nunca teve que usá-lo, meu ponto sempre foi e é, e será, qual deve ser o sentido , e parece que seria uma questão com no entanto resposta.

ps. Outra coisa que aprendi há algum tempo, é nunca ser agressivo com outras opiniões; "tópicos técnicos" para vários programadores, são como religião para religiosos (e alguns caras aqui só se lembraram de mim).

ps2. Eu marquei como resolvido a ser democrático, não quero demonstrar nada, só achei que este site é para boas discussões, e entendi isso. : D

javascript

por Daniel Aranda 15.08.2013 / 20:43

fonte

2 respostas

0

A pergunta que gostaria de fazer ao seu colega de trabalho é por que alguém teria todo o trabalho de criar um objeto com o método toString apropriado e, em seguida, não deseja comparar com 'final' ? Em outras palavras, por que não seria o mesmo tipo seria um problema se os valores fossem semanticamente equivalentes? Certamente ninguém vai escrever código como seu contra-exemplo por acidente.

Na minha opinião, usar uma comparação estrita quando não for necessária viola o princípio de abertura / fechamento . Ele encerra possíveis vias de extensão. Não usar um recurso de uma linguagem para "consistência" é ridículo. Você não escreve i += 1 em vez de i++ , então pode ser consistente com i += 2 . Por todos os meios, seja consistente onde as situações são as mesmas, mas não seja escravo da consistência superficial quando as situações forem diferentes.

A maioria das pessoas pensa no OCP em termos de classes, mas também se aplica a funções. Em geral, significa minimizar a quantidade de código que precisará ser alterada quando você adicionar funcionalidade ao seu programa. Em outras palavras, prefira adicionar código à alteração de código.

99% do tempo, você deve comparar dois valores do mesmo tipo, e aqueles momentos em que a comparação de diferentes tipos é necessária devem ser incrivelmente óbvios e intencionais. Se você não tem idéia se someValue é uma string ou não, você tem um peixe maior para fritar.

por 15.08.2013 / 23:31
fonte

Tags javascript

Meu trabalho não está sendo usado ... o que posso / devo fazer? Opera para desenvolvimento web

score 15 · Answer 1

Sim, por exemplo, typeof x == "string" é funcionalmente exatamente igual a typeof x === "string" .

No entanto, x == " " , não é nem remotamente igual a x === " " , pois uma string cheia de espaços em branco é coerente com 0 e 0 == " " //true ou false == " " //true .

=== é escrito porque a carga cognitiva extra necessária para julgar cada cenário individualmente para possíveis economias de um caractere simplesmente não vale a pena. Aposto que você ou a maioria dos programadores nem sabia sobre as strings de espaço em branco. Seu cérebro precisa confirmar que == "final" não está em nenhum caso, e só então você pode continuar a escrevê-lo.

Você pode me acordar no meio da noite e eu vou recitar todas as regras == e casos de canto de cor, mas isso não significa que eu vou querer passar por eles toda vez

Uma exceção notável é == null , que deve ser memorizada como "indefinida ou nula" e é especialmente suportada pelo jshint que, de outra forma, aplica === .

E espere, tem mais. De especificação

ECMAScript implementations must recognise all of the white space characters defined in Unicode 3.0. Later editions of the Unicode Standard may define other white space characters. ECMAScript implementations may recognise white space characters from later editions of the Unicode Standard

Isso implica que a operação == é implementação definida para comparações de string e boolean / object / number

Por exemplo:

function equals( x ) { return x == "\ufeff\ufeff"; } alert(equals(0));

Dá true no Firefox, mas false no Chrome.

score 0 · Answer 2

A pergunta que gostaria de fazer ao seu colega de trabalho é por que alguém teria todo o trabalho de criar um objeto com o método toString apropriado e, em seguida, não deseja comparar com 'final' ? Em outras palavras, por que não seria o mesmo tipo seria um problema se os valores fossem semanticamente equivalentes? Certamente ninguém vai escrever código como seu contra-exemplo por acidente.

Na minha opinião, usar uma comparação estrita quando não for necessária viola o princípio de abertura / fechamento . Ele encerra possíveis vias de extensão. Não usar um recurso de uma linguagem para "consistência" é ridículo. Você não escreve i += 1 em vez de i++ , então pode ser consistente com i += 2 . Por todos os meios, seja consistente onde as situações são as mesmas, mas não seja escravo da consistência superficial quando as situações forem diferentes.

A maioria das pessoas pensa no OCP em termos de classes, mas também se aplica a funções. Em geral, significa minimizar a quantidade de código que precisará ser alterada quando você adicionar funcionalidade ao seu programa. Em outras palavras, prefira adicionar código à alteração de código.

99% do tempo, você deve comparar dois valores do mesmo tipo, e aqueles momentos em que a comparação de diferentes tipos é necessária devem ser incrivelmente óbvios e intencionais. Se você não tem idéia se someValue é uma string ou não, você tem um peixe maior para fritar.