Quale dovrebbe essere il senso utilizzare un confronto rigoroso con questa stringa specifica: "finale"

Question

Quale dovrebbe essere il senso utilizzare un confronto rigoroso con questa stringa specifica: "finale"

#1 da (15 voti)
#2 da (0 voti)

4

In una recensione del codice che stavo facendo a un collega, l'ho detto qui:

if (someValue === 'final'){

Non ha senso usare il confronto rigoroso perché l'unico modo per passarlo come vero è con un altro valore di stringa uguale a finale.

Penso che sia abbastanza:

if (someValue == 'final'){

Il suo argomento è che un oggetto potrebbe avere un metodo toString che restituisce quella stringa ma rigorosamente non ha lo stesso tipo di dati.

Anche se è vero, come un computer (che non è intelligente come umano), d'altra parte, non ha senso, perché alla fine del modo l'unico modo per passare questo come vero è con una stringa uguale a alla finale. Questo era il suo codice di esempio:

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

Quindi il mio punto qui ragazzi, è che ho bisogno che tu gli spieghi meglio perché non c'è il senso del rigido confronto su una rigida fissa come "finale" perché non c'è modo di passarlo come positivo con un valore diverso di 'final'. (il suo esempio alla fine restituisce la stringa)

Per me il confronto rigoroso è utile per booleani, nulli, non definiti, zero, dove in alcuni casi questi potrebbero passare tutti come falsi. Voglio sentire le tue opinioni.

====== Aggiornamento ==========

È facile identificare che le persone non leggono. La mia domanda era il senso dell'uso === da confrontare con 'finale'. Ho un sacco di spiegazioni su cose che non devo fare. Per il confronto con null, false, zero ecc., Ho detto che ho usato === per casi THOSE ma non per stringhe lunghe. ma le persone hanno cercato di spiegarmi su null, false, zero, ecc. Il verdetto fino ad ora è che non c'è un argomento SOLID (ce ne sono alcuni buoni ma non solidi) che dimostrano il motivo per cui usare === per il confronto con 'final' dovrebbe essere migliore di usare == (leggi di nuovo, è solo questo caso d'uso, sto parlando di uno specifico caso d'uso).

Ho anche parlato con il mio collega, gli ho dato il +1 al codice. Non ho problemi con ===, il mio problema non ha mai dovuto usarlo, il mio punto era sempre ed è, e sarà, quale dovrebbe essere il senso , e sembra che sarebbe una domanda con tuttavia risposta.

ps. l'altra cosa che ho imparato tempo fa è non essere mai aggressivo con altre opinioni; "argomenti tecnici" per diversi programmatori, sono come la religione per i religiosi (e alcuni ragazzi qui mi hanno appena ricordato).

ps2. Ho deciso di essere democratico, non voglio dimostrare nulla, ho solo pensato che questo sito fosse per buone discussioni, e l'ho capito. : D

javascript

posta Daniel Aranda 15.08.2013 - 20:43

fonte

2 risposte

Leggi altre domande sui tag javascript

Qual è il vantaggio della tecnica MoSCoW? "TDD riguarda la progettazione, non la verifica"; concretamente, cosa significa?

score 15 · Answer 1

Sì, ad esempio typeof x == "string" è funzionalmente esattamente uguale a typeof x === "string" .

Tuttavia, x == " " , non è nemmeno lontanamente uguale a x === " " poiché una stringa piena di spazi bianchi esegue una coercizione verso 0 e 0 == " " //true o false == " " //true .

=== è scritto perché il carico cognitivo extra richiesto per giudicare singolarmente ogni scenario per un possibile risparmio di un personaggio non vale la pena. Scommetto che tu o la maggior parte dei programmatori non sapevi nemmeno delle stringhe di spazi vuoti. Il tuo cervello deve confermare che == "final" non si trova in nessun caso d'angolo, e solo dopo puoi continuare a scriverlo.

Puoi svegliarmi nel cuore della notte e reciterò a memoria tutte le regole == e i casi d'angolo, ma ciò non significa che vorrò passare a loro ogni volta è necessario un confronto di uguaglianza.

Un'eccezione degna di nota è == null che dovrebbe essere memorizzata come "non definita o nulla" ed è persino supportata specialmente da jshint che altrimenti applica === .

E aspetta, c'è dell'altro. Da specifiche

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

Questo implica l'operazione == è implementazione definita per confronti di stringhe e booleani / oggetto / numero

Ad esempio:

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

fornisce true su Firefox ma false su Chrome.

score 0 · Answer 2

La domanda che vorrei chiedere al tuo collega è perché qualcuno dovrebbe affrontare tutti i problemi della creazione di un oggetto con un appropriato metodo di toString , quindi non vuoi che sia uguale a 'final' ? In altre parole, perché non sarebbe lo stesso tipo essere un problema se i valori sono semanticamente equivalenti? Certamente nessuno ha intenzione di scrivere codice come il suo contro-esempio per caso.

A mio parere, l'utilizzo di un confronto rigoroso quando non è necessario viola il principio aperto / chiuso . Arresta potenziali vie di estensione. Non usare una caratteristica di una lingua per motivi di "coerenza" è ridicolo. Non scrivi i += 1 invece di i++ in modo da poter essere coerente con i += 2 . Con ogni mezzo, sii coerente dove le situazioni sono le stesse, ma non essere schiavo della consistenza superficiale quando le situazioni sono diverse.

La maggior parte delle persone pensa all'OCP in termini di classi, ma si applica anche alle funzioni. In generale, significa ridurre al minimo la quantità di codice che dovrà essere modificata quando si aggiungono funzionalità al programma. In altre parole, preferisci aggiungere codice al codice che cambia.

Il 99% delle volte, dovresti confrontare due valori dello stesso tipo e quelle in cui è richiesto il confronto tra tipi diversi dovrebbe essere accecantemente ovvio e intenzionale. Se non hai idea se someValue sia o meno una stringa, hai pesci più grandi da friggere.