web-dev-qa-db-fra.com

Est-il préférable de renvoyer `undefined` ou` null` depuis une fonction javascript?

J'ai une fonction que j'ai écrite qui ressemble en gros à ceci:

function getNextCard(searchTerms) {
  // Setup Some Variables

  // Do a bunch of logic to pick the next card based on termed passed through what I'll call here as 'searchTerms' all of this logic is omitted because it's not important for my question.
  // ...

  // If we find a next card to give, than give it
  if (nextCardFound)
    return nextCardFound;

  // Otherwise - I'm returning undefined
  return undefined;
}

Question: Serait-il préférable de retourner "null" ici?

Je peux renvoyer tout ce que je veux - évidemment… Je n'étais tout simplement pas sûr de la meilleure chose à utiliser.

Le code qui appelle cette fonction sait comment traiter l'indéfini (en réalité, cela ne se produira jamais, à moins que quelque chose ne se passe horriblement mal)

La raison pour laquelle je pose cette question est que j'ai entendu quelque part quelque chose qui ressemblait à "Ne pas affecter de variables non définies à des variables" ou quelque chose - cela rendra le débogage plus difficile. Donc, le fait que je puisse voir que null est renvoyé me dit que le retour fonctionne - mais fonctionne fondamentalement de manière similaire à undefined.


Documentation:

Mozilla Docs N'a pas répondu à ma question ... Google n'a pas non plus: \

Cette SO Question - était trop large pour ce que j'essaie de comprendre ici.

61
Jeremy Iglehart

Je ferai valoir qu'il n'y a pas de meilleur moyen, et même les fonctions standard choisissent parfois l'une ou l'autre.

Par exemple:

  • [[Prototype]]

    Les objets ordinaires ont un emplacement interne [[Prototype]], qui détermine de quel autre objet ils héritent. Bien sûr, il doit y avoir un moyen de dire qu'un objet n'hérite d'aucun autre. Dans ce cas, "il n'y a pas d'objet de ce type" est représenté avec null.

  • Object.getOwnPropertyDescriptor

    Il est prévu de renvoyer un descripteur de propriété, c'est-à-dire un objet décrivant une propriété (par exemple, une valeur, une possibilité d'écriture, une énumération et une configurabilité). Cependant, la propriété peut ne pas exister. Dans ce cas, "il n'y a pas de telle propriété" est représenté par undefined.

  • document.getElementById

    Il est prévu de renvoyer l'élément avec l'ID donné. Cependant, il se peut qu'aucun élément ne porte cet ID. Dans ce cas, "il n'y a pas d'élément de ce type" est représenté par null.

Il suffit donc de choisir ce que vous préférez ou pensez être plus logique pour votre cas particulier.

24
Oriol

Undefined fait généralement référence à quelque chose qui n'a pas encore reçu de valeur. Null fait référence à quelque chose qui n'a définitivement aucune valeur. Dans ce cas, je recommanderais de renvoyer un null. Notez qu'une fonction sans valeur de retour spécifiée renvoie implicitement undefined.

A partir de la spécification ECMAScript2015

4.3.10 valeur indéfinie

valeur primitive utilisée lorsqu'une valeur n'a pas été affectée à une variable

4.3.12 valeur nulle

valeur primitive qui représente l'absence intentionnelle de toute valeur d'objet

http://www.ecma-international.org/ecma-262/6.0/#sec-terms-and-definitions-undefined-type

Lectures complémentaires:

Quand null ou undefined est-il utilisé dans JavaScript?

86
chiliNUT

Je vais vous donner mon choix personnel entre les deux.

Ma question simple est: est-ce que la valeur, étant donné une autre entrée/état/contexte, pourrait être définie comme quelque chose?

Si la réponse est oui, utilisez null sinon utilisez undefined. Plus généralement, toute fonction renvoyant un objet doit renvoyer null lorsque l'objet souhaité n'existe pas. Parce qu'il pourrait exister avec un autre intrant/état/contexte.

null représente le absence de valeur pour une entrée/un état/un contexte donnés. Cela signifie implicitement que le concept de la valeur elle-même existe dans le contexte de votre application mais peut être absent. Dans votre exemple, le concept d'une carte suivante existe mais la carte elle-même peut ne pas exister. null devrait être utilisé.

undefined représente implicitement le absence de sens de cette valeur dans le contexte de votre application. Par exemple, si je manipule un objet user avec un ensemble de propriétés donné et que j'essaie d'accéder à la propriété pikatchu. La valeur de cette propriété doit être définie sur undefined car, dans mon contexte, il n’a aucun sens de disposer d’une telle propriété.

22
ngryman

undefined n'est pas quelque chose que vous devriez assigner. Vous voudrez peut-être envisager de retourner autre chose que undefined. Dans votre cas, même si vous ne retournez rien, le résultat sera déjà undefined. Donc, je suggérerais plutôt d’utiliser null.

Considérez cet exemple,

function getSomething() {
     // .. do something
     return undefined;
}

function doSomething() {
     // .. I'm not gonna return anything.
}

var a = getSomething();
var b = doSomething();

Le résultat ci-dessus dans a === b, qui est undefined. La différence est que vous enregistrez 1 exécution d’instruction.

4
vadi taslim

Voici un exemple où undefined a plus de sens que null:

J'utilise une fonction wrapper pour JSON.parse qui convertit son exception en undefined:

// parses s as JSON if possible and returns undefined otherwise
// return undefined iff s is not a string or not parseable as JSON; undefined is not a valid JSON value https://stackoverflow.com/a/14946821/524504
function JSON_parse_or_undefined(s) {
    if ("string" !== typeof s) return undefined

    try {
        const p = JSON.parse(s)
        return p
    } catch (x){}

    return undefined
}

Notez que null est valide en JSON alors que undefined ne l’est pas.

2
masterxilo

Cela dépend de ce que vous devez faire avec la valeur renvoyée.

typeof null retourne un objet. cet objet a une valeur indéfinie

typeof undefined renvoie undefined

2
Dan

Je pense qu'il est très discutable de savoir quoi utiliser. Je préfère un code sémantiquement aussi précis que possible. Je pense donc que undefined est approprié dans ce cas.

Je pense que les assignations null signifient "une variable définie sur rien". Ceci est opposé à undefined qui signifie "cette chose n’existe pas du tout"

Comme une réponse précédente l’a souligné, le renvoi de undefined pose problème, et c’est à vous de décider si cela vous dérange. Cela ne me dérangerait pas.

1
Ryan Laboucane

Je dirais que dans ce cas, null devrait être renvoyé.

Si vous considérez la question du point de vue informatique théorique, alors ndefined est utilisé pour indiquer non-résiliation / non-calculabilité (c'est-à-dire l'espace réservé pour un point non défini x d'un fonction partiellef qui est souvent écrit f(x) = ⊥).

getNextCard semble toutefois pouvoir calculer la carte suivante (si elle existe) et pouvoir également calculer s'il n'y a pas de carte suivante. En d'autres termes, la fonction est totale puisqu'elle se termine pour chaque entrée.

Cela étant dit, une valeur spéciale de terminaison de signalisation sans résultat significatif (c'est-à-dire "il n'y a pas de carte que je peux retourner pour cette entrée") est requise et ceci pour moi est null pas undefined.


REMARQUES:

Vous pouvez constater que cet argument est également pris en charge dans d'autres langages typés, où les terminaisons sans résultat significatif sont exprimées à l'aide de type d'option (parfois aussi appelé type nullable). Un exemple de ceci est Peut-être dans Haskell.

D'autre part, nous ne savons évidemment pas ce que undefined en JavaScript est vraiment supposé signifier. Ainsi, l'analogie avec ndefined est un peu fastidieuse. De plus, puisque nous voulons toujours travailler avec des fonctions globales, cela revient à dire "ne retournez jamais undefined d'une fonction". Ce qui semble être un peu strict, car cela limiterait l'utilisation de undefined aux propriétés/variables qui n'ont pas été définies.

En fin de compte, ma préférence personnelle est de ne jamais retourner undefined où je peux retourner null et je dirais également que c'est la meilleure convention de codage (parce que, entre autres, x !== null est plus court que typeof x !== 'undefined').

1
FK82

La première réponse est juste. Ils ont théoriquement une signification différente. Cependant, il n'est pas toujours évident de savoir lequel choisir.

J'ai tendance à utiliser null dans mon développement bien que je pense que c'est une chose complètement subjective.

Je l'utilise surtout parce que:

  1. la variable non définie peut être écrasée dans les anciens navigateurs, elle est donc un peu plus compliquée à renvoyer. Ce même problème vous oblige à utiliser typeof var === 'undefined' lors de l'obtention des résultats de la fonction. lien

  2. D'autres langues ont tendance à utiliser null largement, beaucoup d'entre elles n'ont même pas d'indéfini (php par exemple). Cela me donne un peu de cohérence lorsque je change rapidement de langue.

0
Maciej Paprocki

D'après mon expérience personnelle, mon opinion personnelle est de ne pas utiliser non défini et nul si vous ne voulez pas bloquer votre code. Au moins, je l'éviterais personnellement. Il y a beaucoup de fonctions en Javascript qui retournent undefined et ok, nous devons les utiliser. Mais lorsque vous concevez votre code, ne l'utilisez pas. Il est important de toujours retourner quelque chose "false" au moins. Si vous avez un tableau par exemple et que vous mappez dessus. Il n'est pas bon de retourner [undefined, undefined.....] ou simplement undefined. Est-ce mieux si vous conservez le type du tableau d'origine. Exemple:

 const mapper:Map <string[],boolean[]>  
['i', 'dont', 'use', 'null or undefined'] -> [false, true, false, true, false]
or ['', dont, '', '', use] 
or al the stuff above and then filter(v => v)
that will keep all undefined and null out

C'est l'idée. J'essaie tout le temps de l'éviter. Parce qu'un null ou undefined peut facilement planter votre code

0
rubendmatos1985