Mi sto spostando per lavorare su una libreria che un altro sviluppatore ha scritto. È pieno di == true e == false , che trovo pazzo frustrante da leggere.
Ho provato a chiedergli di smettere di farlo, ma lui dice semplicemente che rende più semplice capire cosa sta succedendo. C'è una buona ragione per cui questa non è una grande pratica? O è puramente una cosa stilistica?
A seconda della lingua, la semantica non è così banale. In Python:
class X:
def __cmp__(self, other):
return 1
def __nonzero__(self):
return False
if X():
print "'X()' evaluated to: true"
else:
print "'X()' evaluated to: false"
if X() == False:
print "'X() == False' evaluated to: true"
else:
print "'X() == False' evaluated to: false"
if X() == 0:
print "'X() == 0' evaluated to: true"
else:
print "'X() == 0' evaluated to: false"
if X() is False:
print "'X() is False' evaluated to: true"
else:
print "'X() is False' evaluated to: false"
if X() is None:
print "'X() is None' evaluated to: true"
else:
print "'X() is None' evaluated to: false"
stampe
'X()' evaluated to: false
'X() == False' evaluated to: false
'X() == 0' evaluated to: false
'X() is False' evaluated to: false
'X() is None' evaluated to: false
Certamente si può fare un caso, anche in python, per ignorare l'operatore. Il problema è che potrebbe essere fuorviante per chi ha scritto il codice ("python deve essere esattamente come [qualunque sia la lingua], quindi lascerò implicito l'operatore di uguaglianza") e per chi lo leggerà ("intendeva davvero eq confronta implicitamente o dovrebbe essere un esplicito is ? ").
Richiede molto tempo per rintracciare i bug causati da controlli booleani impliciti che dovrebbero essere espliciti (e corretti).
Più grande è il codice, più tempo ci vuole per leggere e più possibilità hai di fraintendere qualcosa.
== true è di 7 caratteri che non contribuiscono al codice e quindi è puro costo, nessun vantaggio.
Non sarei così duro con == false, però. Puoi fare una discussione tra la negazione e un confronto con falso, mentre puoi sostenere che la negazione è superiore non è assolutamente superata come nel caso == true.
Anche io lo trovo frustrante, lassù con
if (condition)
return true;
else
return false;
Mi indica una mancanza di comprensione di cosa fanno i booleani. Qualsiasi ulteriore complessità nel codice è una potenziale fonte di bug, anche se questo è abbastanza banale che potrei rimandare a differenze stilistiche. Puoi abituarti a qualsiasi cosa.
Sono d'accordo con il tuo punto, e anch'io trovo frustrante leggere; tuttavia, quando si ha un solitario negato se la condizione è così:
if(!condition)
doThis();
Mi è stato detto da alcuni sviluppatori senior che può essere facile perdere l'operatore di negazione durante la revisione del codice e preferiscono vedere:
if(condition == false)
doThis();
Sono d'accordo con te che è troppo prolisso; tuttavia, sembra che in alcuni casi, come quello che ho descritto, alcune persone preferiscono averlo.
Non lo è, in generale. Per i linguaggi compilati, l'espressione sarà probabilmente ridotta allo stesso codice macchina, e nei linguaggi interpretati il test esplicito contribuirà a ridurre la possibilità di inserimento indesiderato del codice.
Considera la seguente funzione JavaScript, per esempio, i voti di conteggio su un'ipotetica misura di voto.
function recordVote(YesOrNo) {
if(YesOrNo == true) {
voteYes();
} elseif (YesOrNo == false) {
voteNo();
}
}
Se chiami recordVote(true) o recordVote(false) , il metodo interno viene attivato come previsto. Inoltre, se invochi impropriamente recordVote(42) , recordVote(null) o recordVote("false") , non ottieni alcuna azione, che è desiderata per un'app di voto. (specialmente dal momento che il test standard per la verità, di if(YesOrNo) , avrebbe causato che quest'ultimo registrasse un voto in modo errato.
Ovviamente, nota che i piccoli benefici che ottieni da quanto sopra sono inferiori alla coerenza del tuo codice . Se la libreria ne è già piena, non rimuoverli, ma non aggiungerli se non lo sono. (A meno che, naturalmente, tu non stia rifacendo il tutto e comunque abbia una regola arbitraria di stile per forzare il tuo codice sorgente ad essere il più piccolo possibile ...)
Leggi altre domande sui tag operators