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
.
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.
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.
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:
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é.
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.
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.
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
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.
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'
).
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:
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
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.
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