Il mio primo linguaggio di programmazione è python. E recentemente sto imparando C e javascript.
In javascript, c'è un design che mi ha confuso molto, di default la funzione isNaN
.
Metti da parte le sue strane eccezioni nella specifica (che è difficile da trovare), come isNaN("")
, isNaN(["22"])
.
La cosa più frustrante è che il risultato di isNaN
consuma la mia energia di pensiero, anche se un po 'ogni volta, prima di stabilire un'intuizione a riguardo (che richiede un bel po' di sforzi)
Ma amico, siamo pigri. E questo design non segue l'istinto umano.
Gli esempi seguenti riportano come funziona il mio cervello quando vedo i due tipi di espressioni in python e javascript:
isNaN(n)
false
# THOUGHTS:
# The result of isNaN(n) is false, what does it mean?
# it means n is not a number is false.
# OK, let me think for a while..
# So, I assume it is a number(with hesitation)
type(n) == int
False
# THOUGHTS:
# type(n) == int returns False, what does it mean?
# So it tells us that 'the type of n equals int' is false
# So the type of n is not equal to int!
# I think n is not a int.
Penso che gli esseri umani abbiano la tendenza a presumere che tutto sia Vero all'inizio
Quindi più livelli negativi su affermazione aumenteranno i nostri costi di riconoscimento.
In questa vista, il design di isNaN
è negativo e isN
(isNumber) è una soluzione migliore per la comprensione umana.
Ma da scettico, mi chiedo se possa esserci qualche storia di fondo su questo progetto, per raggiungere una funzionalità importante, l'autore ha scelto questo design come compromesso?
C'era una buona ragione, o si tratta solo di una carenza progettuale (nel senso di umanità)?