Conversion de type automatique dans le monde réel

Points de base

• La conversion de type automatique de JavaScript est à la fois un avantage et un désavantage dans différentes situations. En tant que fonction principale, il convertit les données en un type attendu lorsqu'un opérateur ou une instruction attend un type de données spécifique.
• Selon le résultat de la conversion, les valeurs JavaScript sont appelées "valeurs vraies" ou "fausses valeurs". Il y a six fausses valeurs: false, undefined, null, 0, "", NaN (chaîne vide) et
(non-nombre). Toutes les autres valeurs sont considérées comme vraies.
comment les conversions de type affectent l'évaluation doivent être soigneusement prises en compte pour éviter les pièges. Par exemple, lors de la définition des valeurs par défaut pour les paramètres facultatifs, la vérité des données connues doit être assurée pour empêcher l'échec.
• typeof Bien que les tests explicites utilisant
sont toujours sûrs, l'utilisation de la conversion de type automatique est bénéfique pour les considérations de taille de fichier, car les fichiers plus petits se chargent plus rapidement et utilisent moins de bande passante. Cependant, comprendre comment les langages de programmation gèrent les conversions de type est crucial pour éviter les résultats inattendus.

Il y a des expressions courantes en JavaScript, mais certains puristes de programmation vous diront qu'ils ne sont jamais une bonne idée. Ce que ces expressions ont en commun, c'est qu'ils s'appuient sur la conversion de type automatique - la fonctionnalité principale de JavaScript, qui est à la fois un avantage et un désavantage en fonction de la situation et de votre point de vue.

Donc, dans cet article, je veux prêter une attention particulière à ces deux expressions et considérer dans quels cas ce sont de bonnes idées et qui ne sont pas de bonnes idées.

if() La première expression est une condition simple

:

if (foo) {
}

La deuxième expression est une affectation variable avec des valeurs facultatives:

var x = foo || bar;

foo Si les bar et foo dans les deux exemples sont des booléens, l'expression est simple: si foo est vraie, la première condition passe; à foo, sinon attribue x à bar. x

Mais que se passe-t-il s'ils ne sont pas de simples valeurs booléennes - et si

est un objet, une chaîne ou foo? Et si undefined et foo sont des types de données différents? Pour comprendre comment ces expressions seront calculées, nous devons comprendre comment JavaScript convertit automatiquement entre les types de données. bar

Conversion de type automatique

JavaScript est un langage "dûment tapé", ce qui signifie que chaque fois qu'un opérateur ou une instruction attend un type de données spécifique, JavaScript convertit automatiquement les données en ce type. L'instruction

dans le premier exemple s'attend à une valeur booléenne, donc tout ce qui est défini dans les parenthèses sera converti en valeur booléenne. Il en va de même pour les instructions if() et while(). do...while()

Selon les résultats de ces conversions (c'est-à-dire vraies ou fausses), les valeurs JavaScript sont souvent appelées "vraies" ou "fausses valeurs". La façon la plus simple de le comprendre est: à moins que la valeur ne soit connue pour être une fausse valeur, la valeur est la vraie valeur;

(bien sûr!)

• false
• undefined
• null (nombre zéro)
• 0 (chaîne vide)
• "" (non-nombre)
• NaN Les exceptions notables sont "0" (chaîne zéro) et tous les types d'objets - ce sont de vraies valeurs - cela inclut
tous les constructeurs natifs

, ce qui signifie

Résultats de calcul vrai! (Un peu déroutant, mais en pratique, vous n'avez jamais besoin de créer des valeurs indigènes comme ça.) new Boolean(false) Remarque: La comparaison de deux fausses valeurs ne produit pas toujours les résultats auxquels vous pouvez vous attendre, comme (

), même si les deux sont de fausses valeurs. Il existe des algorithmes assez complexes qui déterminent le fonctionnement des évaluations de l'égalité, et en discuter dépasse le cadre de cet article. Mais si vous êtes intéressé par les détails, vous pouvez consulter l'algorithme de comparaison d'égalité abstrait dans ECMAScript 5.1.

null != false raccourci conditionnel

l'exemple que je vous ai montré au début convertit son expression en valeur booléenne, car l'objet est toujours évalué en vrai et

est évalué en faux, nous pouvons donc utiliser une telle condition pour tester le DOM L'existence de l'élément:

if() null Cela fonctionne toujours de manière fiable lors du traitement des éléments DOM, car la spécification DOM nécessite que les éléments qui n'existent pas de retour

.

if (foo) {
}

Cependant, d'autres situations ne sont pas si claires, comme cet exemple: null

De telles conditions sont souvent utilisées pour indiquer

"Si le paramètre FOO est défini"

var x = foo || bar;

, mais il existe plusieurs situations qui peuvent provoquer une défaillance - c'est-à-dire que

est une fausse valeur. Ainsi, par exemple, s'il s'agit d'une valeur booléenne ou d'une chaîne vide, le code conditionnel n'est pas exécuté même si foo est déjà false défini. foo Ce que nous voulons, c'est le suivant:

Le type de données des paramètres non définis (et autres variables) est "

". Par conséquent, nous pouvons utiliser le comparateur

var element = document.getElementById("whatever");
if (element) {
  // 元素存在
} else {
  // 元素不存在
}

pour tester le type de données du paramètre, puis si

est entièrement défini, la condition passera toujours. Bien sûr, l'expression undefined calcule toujours la valeur booléenne, mais la valeur booléenne qu'il calcule est le résultat typeof de l'expression foo. if() typeof Raccourci d'affectation

Le deuxième exemple que je vous ai montré au début utilise un opérateur logique pour déterminer lequel des deux valeurs doit être attribué à la variable:

Les opérateurs logiques ne renvoient pas les valeurs

booléennes, mais ils s'attendent toujours à des valeurs booléennes

, de sorte que la conversion et les calculs se produiront en interne. Si

function doStuff(foo) {
  if (foo) {
    ...
  }
}

est évalué à vrai, la valeur

de est renvoyée, sinon la valeur de est renvoyée. C'est très utile.

Cette expression est généralement observée dans les gestionnaires d'événements et est utilisée pour définir les paramètres de l'événement basés sur des modèles pris en charge:

if (foo) {
}

Par conséquent, e est calculé comme une valeur booléenne, qui est vraie (objet d'événement) si le modèle de paramètre de l'événement est pris en charge, sinon une fausse valeur (undefined); Sinon, retournez e. window.event

Les expressions du même type sont également souvent utilisées pour attribuer des attributs d'événements, en trouvant des attributs pris en charge en évaluant chaque possibilité:

var x = foo || bar;

Par conséquent, chacune de ces références est évaluée à son tour (de gauche à droite) et le premier calcul est vrai sera retourné. Le premier cas gère le modèle standard, le deuxième cas est pour Internet Explorer et le troisième cas est pour Internet Explorer, lorsqu'un événement peut être déclenché sur un objet de fenêtre (sans la propriété

). srcElement

Cependant, cette expression est également sujette à l'échec, sans connaître la vérité des données. Par exemple, un autre cas d'utilisation courant consiste à définir des valeurs par défaut pour les paramètres facultatifs, mais ce n'est pas bon:

var element = document.getElementById("whatever");
if (element) {
  // 元素存在
} else {
  // 元素不存在
}

Maintenant, si vous êtes sûr que

foo est toujours ou , et si la chaîne vide doit être traitée comme undefined, l'expression est sûre. Mais si ce n'est pas le cas, il doit être redéfini comme un contenu plus précis, par exemple: undefined

function doStuff(foo) {
  if (foo) {
    ...
  }
}

En testant le type contre "String", nous pouvons gérer une variété de cas -

cas non définis et cas où il est défini à tort comme des valeurs non corrigées. Dans ce cas, nous permettons également aux chaînes vides comme entrée valide, mais si nous voulons exclure les chaînes vides, nous devons ajouter une deuxième condition: foo

function doStuff(foo) {
  if (typeof foo != "undefined") {
    ...
  }
}

Il existe d'autres situations étonnamment subtiles qui peuvent causer des problèmes. Par exemple, nous pourrions avoir une fonction de date qui crée un horodatage UNIX à moins que l'horodatage d'entrée ne soit éventuellement défini:

var x = foo || bar;

Si l'entrée est 0, elle échouera - car zéro est une fausse valeur, mais c'est aussi un horodatage valide.

Principes généraux

La leçon générale tirée de tout cela est simple - réfléchissez à la façon dont les conversions de type affecteront l'évaluation et veillez à ne pas tomber dans les pièges que nous rencontrons. Avec une attention et une attention appropriées, vous pouvez toujours utiliser la conversion de type automatique pour raccourcir les conditions et les expressions logiques, le cas échéant.

Mais cela soulève la question - si nous savons que l'utilisation de

est toujours en sécurité, bien que s'appuyer sur la conversion de type automatique n'est parfois pas sûr - alors pourquoi pas typeof toujours est clair? Bien sûr, si la raison de préférer une grammaire plus courte est simplement parce qu'elle tape plus rapidement, alors c'est une raison paresseuse et bâclée.

Mais la vérité est que JavaScript est généralement exécuté sur un réseau public, auquel cas la taille du fichier est importante. Les fichiers plus petits se chargent plus rapidement et utilisent moins de bande passante, et les petits raccourcis de syntaxe peuvent en effet s'accumuler.

L'utilisation d'expressions plus courtes n'est pas une optimisation elle-même, ce n'est qu'un style de programmation, qui utilise pleinement les fonctionnalités linguistiques.

(La section FAQ dans le texte d'origine est omise ici parce que le contenu de cette partie est faiblement lié au sujet de l'article et est plus long, il ne convient donc pas à la conservation des travaux pseudo-originaux.)

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!