Czy lepiej jest zwrócić „undefined” lub „null” z funkcji javascript?

Mam funkcję, którą napisałem, która w zasadzie wygląda tak:

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;
}

Pytanie: Czy lepiej byłoby zwrócić tutaj „null”?

Mogę oddać cokolwiek zechcę - oczywiście ... Po prostu nie byłam pewna, co najlepiej użyć.

Kod, który wywołuje tę funkcję, wie, jak radzić sobie z undefined (tak naprawdę nigdy się nie wydarzy, chyba że coś pójdzie nie tak)

Powodem, dla którego zadaję to pytanie, jest to, że gdzieś usłyszałem coś, co brzmiało jak „Nie przypisuj wartości niezdefiniowanej do zmiennych” lub coś takiego - że utrudni to debugowanie. Tak więc fakt, że widzę, że nulljest przekazywany z powrotem, mówi mi, że zwrot działa - ale zasadniczo działa podobnie do undefined.

Dokumentacja:

Dokumenty Mozilla nie odpowiedziały na moje pytanie ... Google też nie: \

To TAK pytanie - było zbyt szerokie, jak na to, co próbuję tutaj zrozumieć.

Będę argumentował, że nie ma najlepszego sposobu, a nawet standardowe funkcje czasami wybierają jedną lub drugą.

Na przykład:

• [[Prototyp]]

  Zwykłe obiekty mają wewnętrzną szczelinę [[Prototype]], która określa, z jakiego innego obiektu dziedziczą. Oczywiście musi istnieć sposób, aby powiedzieć, że obiekt nie dziedziczy po żadnym innym. W tym przypadku „nie ma takiego obiektu” jest reprezentowane za pomocą null.

• Object.getOwnPropertyDescriptor

  Oczekuje się, że zwróci deskryptor właściwości, czyli obiekt, który opisuje właściwość (np. Wartość, możliwość zapisu, wyliczalność i konfigurowalność). Jednak nieruchomość może nie istnieć. W tym przypadku „nie ma takiej właściwości” jest reprezentowane za pomocą undefined.

• document.getElementById

  Oczekuje się, że zwróci element o podanym identyfikatorze. Jednak może nie być elementu z tym identyfikatorem. W tym przypadku „nie ma takiego elementu” jest reprezentowane za pomocą null.

Więc po prostu wybierz to, co wolisz lub uważasz, że ma większy sens w Twoim konkretnym przypadku.

Undefined zazwyczaj odnosi się do czegoś, co nie zostało jeszcze przypisane (jeszcze). Null odnosi się do czegoś, co ostatecznie nie ma wartości. W takim przypadku zalecam zwrócenie wartości null. Zwróć uwagę, że funkcja bez określonej wartości zwracanej niejawnie zwraca wartość undefined.

Ze specyfikacji ECMAScript2015

4.3.10 wartość niezdefiniowana

wartość pierwotna używana, gdy zmiennej nie przypisano wartości

4.3.12 wartość zerowa

wartość pierwotna, która reprezentuje celowy brak wartości obiektu

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

Czytaj dalej:

Kiedy wartość null lub undefined jest używana w JavaScript?

Podam ci mój osobisty uparty sposób wyboru między tymi dwoma.

Moje proste pytanie brzmi: czy można zdefiniować wartość, biorąc pod uwagę inne dane wejściowe / stan / kontekst?

Jeśli odpowiedź brzmi tak, użyj nullelse użyj undefined. Mówiąc bardziej ogólnie, każda funkcja zwracająca obiekt powinna zwrócić, nullgdy zamierzony obiekt nie istnieje. Ponieważ może istnieć przy innym wejściu / stanie / kontekście.

nullreprezentuje brak wartości dla danego wejścia / stanu / kontekstu. To pośrednio oznacza, że pojęcie samej wartości istnieje w kontekście twojej aplikacji, ale może być nieobecne. W twoim przykładzie istnieje koncepcja następnej karty, ale sama karta może nie istnieć. nullpowinien być używany.

undefinedniejawnie reprezentuje brak znaczenia tej wartości w kontekście aplikacji. Na przykład, jeśli manipuluję userobiektem z podanym zestawem właściwości i próbuję uzyskać dostęp do właściwości pikatchu. Wartość tej właściwości powinna być ustawiona na, undefinedponieważ w moim kontekście nie ma sensu mieć takiej właściwości.

undefinednie jest czymś, do czego powinieneś przypisywać. Możesz rozważyć zwrot czegoś innego niż undefined. W twoim przypadku, nawet jeśli w ogóle nic nie zwrócisz, wynik będzie undefinedjuż. Więc proponuję nullzamiast tego.

Rozważ tę próbkę,

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

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

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

Wynik powyższej próbki to a === b, czyli undefined. Różnica polega na tym, że zapisujesz wykonanie 1 instrukcji.

Zależy od tego, co musisz zrobić ze zwróconą wartością.

typeof null zwraca obiekt. ten obiekt ma wartość undefined

typeof undefined zwraca undefined

Oto przykład, w którym undefinedma więcej sensu niżnull :

Używam funkcji opakowującej, JSON.parsektóra konwertuje wyjątek na 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
}

Zauważ, że nulljest to poprawne w JSON, a undefinednie.

Twierdziłbym, że w tym przypadku nullpowinien zostać zwrócony.

Jeśli wziąć pod uwagę kwestię z teoretycznego punktu widzenia informatyki następnie niezdefiniowana służy do wskazania zakaz wypowiedzenia / non-obliczalności (czyli zastępczy nieokreślonym punkcie xz częściową funkcją f , która jest często napisanef(x) = ⊥ ).

getNextCardwydaje się jednak, że jest w stanie obliczyć następną kartę (jeśli istnieje), a także być w stanie obliczyć, jeśli nie ma następnej karty. Innymi słowy, funkcja jest całkowita ponieważ kończy się dla każdego wejścia.

Mając to na uwadze, wymagana jest specjalna wartość zakończenia sygnalizacji bez znaczącego wyniku (tj. „Nie ma karty, którą mogę zwrócić dla tego wejścia”), a dla mnie nullnie jest undefined.

UWAGI:

Możesz zobaczyć pewne wsparcie dla tego argumentu w niektórych innych językach z typami typów, gdzie zakończenie bez znaczącego wyniku jest wyrażane za pomocą typu opcji (czasami nazywanego również typem dopuszczającym wartość null ). Przykładem tego jest Może w Haskell .

Z drugiej strony, oczywiście nie wiemy, co undefinedtak naprawdę ma oznaczać JavaScript. Tak więc analogia do undefined jest nieco wątpliwa. Co więcej, ponieważ zawsze chcemy pracować z funkcjami całkowitymi, oznacza to „nigdy nie wracaj undefinedz funkcji”. Co wydaje się być nieco surowe, ponieważ ograniczyłoby użycie undefineddo właściwości / zmiennych, które nie zostały ustawione.

Ostatecznie wolę nigdy nie wracać undefinedtam, gdzie mogę wrócić, nulli argumentowałbym również, że jest to lepsza konwencja kodowania (ponieważ między innymi x !== nulljest krótsza niż typeof x !== 'undefined').

Pierwsza odpowiedź jest prawidłowa. Mają teoretycznie inne znaczenie. Jednak nie zawsze jest jasne, który wybrać.

Zwykle używam null w moim rozwoju, chociaż myślę, że jest to całkowicie subiektywne.

Używam tego głównie dlatego, że:

1. niezdefiniowana zmienna może zostać nadpisana w starszych przeglądarkach, więc jej zwrócenie jest nieco bardziej skomplikowane. Ten sam problem zmusza do korzystania typeof var === 'undefined'z wyników funkcji. połączyć

2. Inne języki często używają wartości null w szerokim zakresie, wiele z nich nie ma nawet wartości undefined (na przykład php). To daje mi pewną konsekwencję podczas szybkiego przełączania się między językami.

Myślę, że jest bardzo dyskusyjne, czego użyć. Wolę kod, który jest semantycznie tak dokładny, jak to tylko możliwe, więc myślęundefined jest odpowiedni w tym przypadku.

Myślę o nullprzypisaniach jako o „zmiennej ustawionej na nic”. To w przeciwieństwie doundefined znaczenia „tego w ogóle nie ma”

Jak wskazano w poprzedniej odpowiedzi, powrót undefinedwiąże się z problemami i od Ciebie zależy, czy to Ci przeszkadza. Nie przeszkadzałoby mi to.

Moja osobista opinia, zgodnie z moim doświadczeniem, brzmi: nie używaj undefined i null, jeśli nie chcesz zepsuć kodu. Przynajmniej uniknąłbym tego osobiście. W JavaScript jest wiele funkcji, które zwracają wartość undefined i ok, musimy do tego użyć. Ale kiedy projektujesz swój kod, nie używaj go. Ważne jest, aby zawsze "false"przynajmniej coś zwrócić . Na przykład, jeśli masz tablicę i mapujesz ją. Nie jest dobrze wracać [undefined, undefined.....]ani po prostu undefined. Lepiej, jeśli zachowasz typ oryginalnej tablicy. Przykład:

 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

To jest pomysł. Cały czas staram się tego uniknąć. Ponieważ nulllub undefinedmoże łatwo spowodować awarię kodu