Automatische Konvertierung in der realen Welt

Kernpunkte

Die automatische Konvertierung von
• JavaScript ist sowohl ein Vorteil als auch ein Nachteil in verschiedenen Situationen. Als Kernfunktion konvertiert es Daten in einen erwarteten Typ, wenn ein Bediener oder eine Anweisung einen bestimmten Datentyp erwartet.
• Gemäß dem Konvertierungsergebnis werden JavaScript -Werte als "wahre Werte" oder "falsche Werte" bezeichnet. Es gibt sechs falsche Werte: false, undefined, null, 0, "", NaN (leere Zeichenfolge) und
(nicht nummer). Alle anderen Werte werden als wahr angesehen.
Wie Typumwandlungen die Bewertung beeinflussen, muss sorgfältig in Betracht gezogen werden, um Fallstricke zu vermeiden. Wenn beispielsweise die Standardwerte für optionale Parameter definiert werden, muss beispielsweise die Wahrheit bekannter Daten sichergestellt werden, um einen Fehler zu verhindern.
• typeof Während explizite Tests mit
immer sicher sind, ist die Verwendung der automatischen Typumwandlung für Überlegungen zur Dateigröße von Vorteil, da kleinere Dateien schneller geladen werden und weniger Bandbreite verwenden. Es ist jedoch entscheidend zu verstehen, wie Programmiersprachen mit Typumwandlungen umgehen, um unerwartete Ergebnisse zu vermeiden.

Es gibt einige Ausdrücke, die in JavaScript üblich sind, aber einige Programmierpuristen werden Ihnen sagen, dass sie niemals eine gute Idee sind. Diese Ausdrücke haben gemeinsam, dass sie sich auf die automatische Konvertierung angewiesen haben - die Kernfunktionalität von JavaScript, die je nach Situation und Ihrer Sichtweise sowohl ein Vorteil als auch ein Nachteil ist.

In diesem Artikel möchte ich diese beiden Ausdrücke besonders aufmerksam machen und berücksichtigen, in welchen Fällen sie gute Ideen sind und welche keine guten Ideen sind.

if() Der erste Ausdruck ist eine einfache

Bedingung:

<code class="language-javascript">if (foo) {
}</code>

Der zweite Ausdruck ist eine variable Zuordnung mit optionalen Werten:

<code class="language-javascript">var x = foo || bar;</code>

foo Wenn die bar und foo in beiden Beispielen Booleschen sind, ist der Ausdruck einfach: Wenn foo wahr ist, ist die erste Bedingung erfolgt; zu foo, ansonsten weist x bar zu. x

Aber was ist, wenn sie keine einfachen booleschen Werte sind- was ist, wenn

ein Objekt, ein String oder foo ist? Was ist, wenn undefined und foo unterschiedliche Datentypen sind? Um zu verstehen, wie diese Ausdrücke berechnet werden, müssen wir verstehen, wie JavaScript automatisch zwischen Datentypen umwandelt. bar

automatischer Typumwandlung

JavaScript ist eine "locker getippte" Sprache, was bedeutet, dass JavaScript, wenn ein Bediener oder eine Anweisung einen bestimmten Datentyp erwartet, automatisch Daten in diesen Typ umwandelt. Die

-Anweisung im ersten Beispiel erwartet einen booleschen Wert, sodass alles, was in den Klammern definiert ist, in einen booleschen Wert umgewandelt wird. Gleiches gilt für die Aussagen if() und while(). do...while()

Gemäß den Ergebnissen solcher Konvertierungen (d. H. Richtig oder falsch) werden JavaScript -Werte häufig als "wahr" oder "falsche Werte" bezeichnet. Der einfachste Weg zu verstehen ist: Wenn der Wert ein falscher Wert ist, ist der Wert der wahre Wert;

(natürlich!)

• false
• undefined
• null (Nummer Null)
• 0 (leere Zeichenfolge)
• "" (nicht nummer)
• NaN bemerkenswerte Ausnahmen sind "0" (Zeichenfolge Null) und alle Arten von Objekten - sie sind echte Werte - dies schließt
alle

nativen Konstruktoren ein, was bedeutet

Berechnungsergebnisse wahr! (Ein wenig verwirrend, aber in der Praxis müssen Sie nie so native Werte erstellen.) new Boolean(false) Hinweis: Der Vergleich von zwei falschen Werten erzeugt nicht immer die Ergebnisse, die Sie möglicherweise erwarten, z. B. (

), selbst wenn beide falsche Werte sind. Es gibt einige ziemlich komplexe Algorithmen, die bestimmen, wie Gleichstellungsbewertungen funktionieren, und die Diskussion ist jenseits des Rahmens dieses Artikels. Wenn Sie jedoch an Details interessiert sind, können Sie sich den Abstract Equality -Vergleichsalgorithmus in ECMAScript 5.1 ansehen.

null != false bedingte Verknüpfung

Das Beispiel, das ich Ihnen zu Beginn gezeigt habe Existenz des Elements:

Dies funktioniert immer zuverlässig, wenn die DOM -Elemente verarbeitet werden, da die DOM -Spezifikation erforderlich ist, dass Elemente, die nicht existieren, if(). null

andere Situationen sind jedoch nicht so klar, wie beispielsweise dieses Beispiel:

<code class="language-javascript">if (foo) {
}</code>

null solche Bedingungen werden häufig verwendet, um

"Wenn der FOO -Parameter definiert ist"

, es gibt jedoch mehrere Situationen, die ein Versagen verursachen können - d. H.

ist ein falscher Wert. Wenn es sich beispielsweise um einen booleschen Wert

<code class="language-javascript">var x = foo || bar;</code>

oder eine leere Zeichenfolge handelt, wird der bedingte Code nicht ausgeführt, selbst wenn

bereits definiert ist. foo false Was wir wollen: foo Der Datentyp der undefinierten Parameter (und anderer Variablen) lautet "

". Daher können wir den

-Palator verwenden, um den Datentyp des Parameters zu testen, und wenn

vollständig definiert ist, wird die Bedingung immer bestehen. Natürlich berechnet der Ausdruck

<code class="language-javascript">var element = document.getElementById("whatever");
if (element) {
  // 元素存在
} else {
  // 元素不存在
}</code>

immer noch den booleschen Wert, aber der von ihm berechnete Boolesche Wert ist das Ergebnis der

-Spression. undefined typeof foo Zuordnungsverknüpfung if() typeof Das zweite Beispiel, das ich Ihnen zu Beginn gezeigt habe

logische Operatoren geben die booleschen Werte nicht zurück, aber sie erwarten immer noch

boolesche Werte, sodass die Konvertierung und Berechnungen intern erfolgen. Wenn auf True bewertet wird, wird der Wert

zurückgegeben, andernfalls wird der Wert von

zurückgegeben. Das ist sehr nützlich.

Dieser Ausdruck wird normalerweise bei Ereignishandlern gesehen und wird verwendet, um Ereignisparameter basierend auf unterstützten Modellen zu definieren:

<code class="language-javascript">if (foo) {
}</code>

wird daher e als boolescher Wert berechnet, der wahr ist (Ereignisobjekt), wenn das Ereignisparametermodell unterstützt wird, ansonsten ein falscher Wert (undefined); Ansonsten return e. window.event

Ausdrücke desselben Typs werden häufig auch zum Zuweisen von Ereignisattributen verwendet, wobei er unterstützte Attribute finden, indem jede Möglichkeit bewertet wird:

<code class="language-javascript">var x = foo || bar;</code>

Daher wird jede dieser Referenzen wiederum bewertet (von links nach rechts) und die erste Berechnung wird zurückgegeben. Der erste Fall übernimmt das Standardmodell, der zweite Fall ist für Internet Explorer und der dritte Fall für Internet Explorer, wenn ein Ereignis auf einem Fensterobjekt ausgelöst werden kann (ohne die Eigenschaft

). srcElement

Dieser Ausdruck ist jedoch auch anfällig für Scheitern, ohne die Wahrheit der Daten zu kennen. Ein weiterer häufiger Anwendungsfall besteht beispielsweise darin, Standardwerte für optionale Parameter zu definieren, dies ist jedoch nicht gut:

<code class="language-javascript">var element = document.getElementById("whatever");
if (element) {
  // 元素存在
} else {
  // 元素不存在
}</code>

Wenn Sie nun sicher sind, ist

foo immer oder , und wenn die leere Zeichenfolge als undefined behandelt werden sollte, ist der Ausdruck sicher. Aber wenn dies nicht der Fall ist, muss es als genaueren Inhalt neu definiert werden, zum Beispiel: undefined

<code class="language-javascript">function doStuff(foo) {
  if (foo) {
    ...
  }
}</code>

Durch das Testen des Typs gegen "String" können wir eine Vielzahl von Fällen verarbeiten -

undefinierte Fälle und Fälle, in denen er falsch als Nicht -Stringwerte definiert wird. In diesem Fall erlauben wir auch leere Zeichenfolgen als gültige Eingabe. Wenn wir jedoch leere Zeichenfolgen ausschließen möchten, müssen wir eine zweite Bedingung hinzufügen: foo

<code class="language-javascript">function doStuff(foo) {
  if (typeof foo != "undefined") {
    ...
  }
}</code>

Es gibt einige andere überraschend subtile Situationen, die Probleme verursachen können. Zum Beispiel haben wir möglicherweise eine Datumsfunktion, die einen Unix -Zeitstempel erstellt, es sei denn, der Zeitstempel der Eingabe ist optional definiert:

<code class="language-javascript">var x = foo || bar;</code>

Wenn die Eingabe 0 ist, fällt es fehl - da Null ein falscher Wert ist, aber auch ein gültiger Zeitstempel ist.

Allgemeine Prinzipien

Die allgemeine Lektion, die aus all dem gelernt wurde, ist einfach - Überlegen Sie, wie sich die Konvertierungen von Typen auf die Bewertung auswirken, und achten Sie darauf, nicht in die Fallen zu fallen, denen wir begegnen. Mit ordnungsgemäßer Aufmerksamkeit und Aufmerksamkeit können Sie weiterhin automatische Typumwandlungen verwenden, um Bedingungen und logische Ausdrücke gegebenenfalls zu verkürzen.

Aber das wirft die Frage auf - wenn wir wissen, dass die Verwendung von

immer sicher ist, wenn es manchmal nicht sicher ist, sich auf automatische Typumwandlungen zu verlassen -, warum nicht immer typeof ist dann klar? Wenn der Grund für die Bevorzugung einer kürzeren Grammatik einfach darauf zurückzuführen ist, dass sie schneller typisiert, ist dies ein fauler und schlampiger Grund. Aber die Wahrheit ist, dass JavaScript normalerweise über ein öffentliches Netzwerk ausgeführt wird. In diesem Fall ist die Dateigröße wichtig. Kleinere Dateien laden schneller und verwenden weniger Bandbreite, und kleine Syntaxverknüpfungen können sich tatsächlich ansammeln.

Die Verwendung kürzerer Ausdrücke ist keine Optimierung selbst, sondern nur ein Programmierstil, der die Sprachfunktionen voll ausnutzt.

(Der FAQ-Abschnitt im Originaltext wird hier weggelassen, da der Inhalt dieses Teils schwach mit dem Thema des Artikels zusammenhängt und länger ist. Daher ist er nicht für die Aufbewahrung in Pseudooriginalwerken geeignet.)

Das obige ist der detaillierte Inhalt vonAutomatische Konvertierung in der realen Welt. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!