Quelle est la raison d'utiliser null au lieu d'indéfini dans JavaScript?

J'écris du JavaScript depuis assez longtemps maintenant, et je n'ai jamais eu de raison de l'utiliser null. Il semble que ce undefinedsoit toujours préférable et sert le même objectif par programme. Quelles sont les raisons pratiques à utiliser à la nullplace de undefined?

Null et undefined sont essentiellement deux valeurs différentes qui signifient la même chose. La seule différence réside dans les conventions d'utilisation de ces derniers dans votre système. Comme certains l'ont mentionné, certaines personnes utilisent null pour signifier "aucun objet" où vous pouvez parfois obtenir un objet alors que non défini signifie qu'aucun objet n'était attendu (ou qu'il y avait une erreur). Mon problème avec cela est qu'il est complètement arbitraire et totalement inutile.

Cela dit, il y a une différence majeure: les variables qui ne sont pas initialisées (y compris les paramètres de fonction où aucun argument n'a été passé, entre autres) sont toujours indéfinies.

C'est pourquoi dans mon code je n'utilise jamais null à moins que quelque chose que je ne contrôle pas retourne null (correspondance regex par exemple). La beauté de ceci est que cela simule beaucoup les choses. Je n'ai jamais à vérifier si x === undefined || x === nul. Et si vous avez l'habitude d'utiliser == ou simplement des trucs comme if (x) .... Arrête ça. !xévaluera à vrai pour une chaîne vide, 0, null, NaN - c'est-à-dire des choses que vous ne voulez probablement pas. Si vous voulez écrire du javascript qui n'est pas terrible, utilisez toujours triple equals === et n'utilisez jamais null (utilisez plutôt undefined). Cela vous facilitera la vie.

Je n'ai pas vraiment de réponse, mais selon Nicholas C. Zakas , page 30 de son livre " Professional JavaScript for Web Developers " :

Lors de la définition d'une variable destinée à contenir ultérieurement un objet, il est conseillé d'initialiser la variable nullpar opposition à autre chose. De cette façon, vous pouvez vérifier explicitement la valeur nullpour déterminer si la variable a été remplie avec une référence d'objet ultérieurement

À la fin de la journée, parce que les deux nullet undefinedcontraignent à la même valeur ( Boolean(undefined) === false && Boolean(null) === false), vous pouvez techniquement utiliser l'un ou l'autre pour faire le travail. Cependant, il y a la bonne manière, l'OMI.

1. Laissez l'utilisation de undefinedau compilateur JavaScript.

   undefinedest utilisé pour décrire des variables qui ne pointent pas vers une référence. C'est quelque chose que le compilateur JS prendra soin de vous. Au moment de la compilation, le moteur JS définira la valeur de toutes les variables levées sur undefined. Au fur et à mesure que le moteur parcourt le code et que les valeurs deviennent disponibles, le moteur attribue des valeurs respectives aux variables respectives. Pour les variables pour lesquelles il n'a pas trouvé de valeurs, les variables continueraient à maintenir une référence à la primitive undefined.

2. N'utilisez NULL que si vous souhaitez explicitement désigner la valeur d'une variable comme n'ayant "aucune valeur".

   Comme l'indique @ com2gz: nullest utilisé pour définir quelque chose de vide par programmation. undefinedveut dire que la référence n'existe pas. Une nullvaleur a une référence définie à «rien». Si vous appelez une propriété non existante d'un objet, vous obtiendrez undefined. Si je veux rendre cette propriété intentionnellement vide, alors ce doit être nullpour que vous sachiez que c'est exprès.

TLDR; N'utilisez pas le undefinedprimitif. C'est une valeur que le compilateur JS définira automatiquement pour vous lorsque vous déclarez des variables sans affectation ou si vous essayez d'accéder aux propriétés d'objets pour lesquels il n'y a pas de référence. D'autre part, utilisez nullsi et seulement si vous voulez intentionnellement qu'une variable n'ait «aucune valeur».

Je n'ai jamais défini explicitement quoi que ce soit sur undefined (et je n'ai pas rencontré cela dans les nombreuses bases de code avec lesquelles j'ai interagi). De plus, j'utilise rarement null. Les seules fois que j'utilise, nullc'est lorsque je veux désigner la valeur d'un argument d'une fonction comme n'ayant aucune valeur, c'est-à-dire:

function printArguments(a,b) {
  console.log(a,b);
}

printArguments(null, " hello") // logs: null hello

indéfini, c'est là où aucune notion de la chose n'existe; il n'a pas de type, et il n'a jamais été référencé auparavant dans cette portée; null est l'endroit où la chose est connue pour exister, mais elle n'a aucune valeur.

Chacun a sa propre façon de coder et sa propre sémantique interne, mais au fil des ans, j'ai trouvé que c'était le conseil le plus intuitif que je donne aux gens qui se posent cette question: en cas de doute, faites ce que fait JavaScript .

Disons que vous travaillez avec des propriétés d'objet comme des options pour un plugin jQuery ... demandez-vous quelle valeur JavaScript donne une propriété qui n'a pas encore été définie - la réponse est undefined. Donc, dans ce contexte, je initialiserais ces types de choses avec 'undefined' pour être cohérent avec JavaScript (pour les variables, vous pouvez le faire à la var myVar;place de var myVar = undefined;).

Maintenant, disons que vous faites une manipulation DOM ... quelle valeur JavaScript attribue-t-il aux éléments inexistants? La réponse est null. C'est la valeur avec laquelle je initialiserais si vous créez une variable d'espace réservé qui contiendra plus tard une référence à un élément, un fragment de document ou similaire lié au DOM.

Si vous travaillez avec JSON, un cas particulier doit être fait: pour les valeurs de propriété non définies, vous devez les définir sur ""ou nullparce qu'une valeur de undefinedn'est pas considérée comme le format JSON approprié.

Cela dit, comme une affiche précédente l'a exprimé, si vous constatez que vous initialisez des éléments avec nullou undefinedplus d'une fois dans une lune bleue, vous devriez peut-être reconsidérer la façon dont vous codez votre application.

Vous pourriez adopter la convention suggérée ici, mais il n'y a vraiment aucune bonne raison de le faire. Il n'est pas utilisé de manière suffisamment cohérente pour être significatif.

Pour rendre la convention utile, vous devez d'abord savoir que la fonction appelée suit la convention. Ensuite, vous devez tester explicitement la valeur renvoyée et décider quoi faire. Si vous êtes indéfini , vous pouvez supposer qu'une erreur s'est produite et que la fonction appelée était au courant . Mais si une erreur s'est produite et que la fonction le savait, et qu'il est utile de l'envoyer dans un environnement plus large, pourquoi ne pas utiliser un objet d'erreur? c'est-à-dire jeter une erreur?

Donc en fin de compte, la convention est pratiquement inutile dans autre chose que de très petits programmes dans des environnements simples.

Une propriété utile dans null qui n'est pas définie ne qualifie pas:

> null + 3
3
> undefined + 3
NaN

J'utilise nullquand je veux «désactiver» une valeur numérique, ou en initialiser. Ma dernière utilisation était de manipuler la transformation css:

const transforms = { perspective : null, rotateX : null };
// if already set, increase, if not, set to x
runTimeFunction((x) => { trasforms.perspective += x; });
// still useful, as setting perspective to 0 is different than turning it off
runTimeFunction2((x) => { transforms.perspective = null; });

// toCss will check for 'null' values and not set then at all
runTimeFunction3(() => { el.style.transform = toCss(transforms); });

Je ne sais pas si je devrais utiliser cette propriété pensée ...

Les nœuds et éléments DOM ne sont pas indéfinis, mais peuvent être nuls.

• Le nextSibling du dernier enfant d'un élément est nul.

• Le previousSibling du premier enfant est nul.

• Une référence document.getElementById est nulle si l'élément n'existe pas dans le document.

Mais dans aucun de ces cas, la valeur n'est indéfinie ; il n'y a tout simplement pas de nœud là-bas.

Quelques-uns ont dit qu'il était possible d'initialiser des objets avec null. Je voulais juste souligner que les valeurs par défaut des arguments de déstructuration ne fonctionnent pas null. Par exemple:

const test = ({ name } = {}) => {
  console.log(name)
}

test() // logs undefined
test(null) // throws error

Cela nécessite d'effectuer des nullvérifications avant d'appeler la fonction, ce qui peut arriver souvent.

Je travaille sur cette question exacte en ce moment et j'examine la philosophie suivante:

1. Toute fonction destinée à renvoyer un résultat doit retourner null si elle ne parvient pas à trouver un résultat
2. Toute fonction qui n'est PAS destinée à renvoyer un résultat renvoie implicitement undefined.

Pour moi, cette question est importante parce que quiconque appelle une fonction qui renvoie un résultat ne devrait avoir aucune question quant à savoir s'il faut tester undefined vs null.

Cette réponse ne tente pas de traiter:

1. Valeurs de propriété nulles ou non définies
2. Les variables au sein de vos fonctions sont nulles et non définies

À mon avis, les variables sont votre propre entreprise et ne font pas partie de votre API, et les propriétés de tout système OO sont définies et doivent donc être définies avec une valeur différente de ce qu'elles seraient si elles n'étaient pas définies (nul pour défini, indéfini est ce que vous get lors de l'accès à quelque chose qui n'est pas dans votre objet).

Voici une raison: var undefined = 1 c'est du javascript légal, mais var null = 1c'est une erreur de syntaxe. La différence est qu'il nulls'agit d'un mot-clé de langue, alors que ce undefinedn'est pas le cas pour une raison quelconque.

Si votre code repose sur des comparaisons undefinedcomme s'il s'agissait d'un mot-clé ( if (foo == undefined)- une erreur très facile à faire) qui ne fonctionne que parce que personne n'a défini une variable avec ce nom. Tout ce code est vulnérable à la définition accidentelle ou malveillante d'une variable globale portant ce nom. Bien sûr, nous savons tous que définir accidentellement une variable globale est totalement impossible en javascript ...

Je veux juste ajouter qu'avec l'utilisation de certaines bibliothèques javascript, null et undefined peuvent avoir des conséquences inattendues.

Par exemple, la getfonction de lodash , qui accepte une valeur par défaut comme troisième argument:

const user = {
  address: {
    block: null,
    unit: undefined,
  }
}
console.log(_.get(user, 'address.block', 'Default Value')) // prints null
console.log(_.get(user, 'address.unit', 'Default Value')) // prints 'Default Value'
console.log(_.get(user, 'address.postalCode', 'Default Value')) // prints 'Default Value'

Autre exemple: si vous utilisez defaultProps dans React, si une propriété est transmise null, les accessoires par défaut ne sont pas utilisés car null est interprété comme une valeur définie . par exemple

class MyComponent extends React.Component {
   static defaultProps = {
      callback: () => {console.log('COMPONENT MOUNTED')},
   }
   componentDidMount() {
      this.props.callback();
   }
}
//in some other component
<MyComponent />   // Console WILL print "COMPONENT MOUNTED"
<MyComponent callback={null}/>   // Console will NOT print "COMPONENT MOUNTED"
<MyComponent callback={undefined}/>   // Console WILL print "COMPONENT MOUNTED"

Je ne suis absolument pas d'accord pour dire que l'utilisation nulle ou non définie n'est pas nécessaire. undefined est une chose qui maintient en vie tout le processus de chaînage de prototype. Ainsi, le compilateur uniquement avec null ne peut pas vérifier si cette propriété est juste égale à null ou n'est pas définie dans le prototype de point de terminaison. Dans d'autres langages typés dynamiques (par exemple Python), il lève une exception si vous voulez accéder à une propriété non définie, mais pour les langages basés sur des prototypes, le compilateur doit également vérifier les prototypes parents et voici l'endroit où le besoin indéfini est le plus important.

Toute la signification de l'utilisation de null est simplement de lier une variable ou une propriété avec un objet qui est singleton et qui a une signification de vide, et l'utilisation de null a également des objectifs de performance. Ce code 2 a un temps d'exécution différent.

var p1 = function(){this.value = 1};
var big_array = new Array(100000000).fill(1).map((x, index)=>{
    p = new p1();
    if(index > 50000000){
       p.x = "some_string";
    }

    return p;
});
big_array.reduce((sum, p)=> sum + p.value, 0)

var p2 = function(){this.value = 1, p.x = null};
var big_array = new Array(100000000).fill(1).map((x, index)=>{
    p = new p2();
    if(index > 50000000){
       p.x = "some_string";
    }

    return p; 
});
big_array.reduce((sum, p)=> sum + p.value, 0)

Variable inconnue: undefined.

Variable connue encore aucune valeur: null.

1. Vous recevez un objet à partir d' un serveur, server_object.
2. Vous faites référence server_object.errj. Cela vous dit que c'est undefined. Cela signifie qu'il ne sait pas ce que c'est.
3. Maintenant, vous faites référence server_object.err. Cela vous dit que c'est null. Cela signifie que vous faites référence à une variable correcte mais qu'elle est vide; donc pas d'erreur.

Le problème est lorsque vous déclarez un nom de variable sans valeur ( var hello) js déclare que undefined: cette variable n'existe pas; alors que les programmeurs veulent surtout dire: «Je ne lui ai pas encore donné de valeur», la définition de null.

Ainsi, le comportement par défaut d'un programmeur - déclarer une variable sans valeur comme rien - est en contradiction avec js - en la déclarant comme non existante. Et d'ailleurs, !undefinedet !nullsont les deuxtrue donc la plupart des programmeurs les traitent comme équivalents.

Vous pouvez bien sûr vous assurer que vous le faites toujours, var hello = nullmais la plupart ne jetteront pas leur code en tant que tel pour garantir la cohérence du type dans un langage délibérément mal typé, quand eux et l' !opérateur traitent les deux undefinedet nullcomme équivalents.