Jak najlepiej ustalić, czy argument nie jest wysyłany do funkcji JavaScript

Widziałem teraz 2 metody określania, czy argument został przekazany do funkcji JavaScript. Zastanawiam się, czy jedna metoda jest lepsza od drugiej, czy też jest po prostu nieodpowiednia w użyciu?

 function Test(argument1, argument2) {
      if (Test.arguments.length == 1) argument2 = 'blah';

      alert(argument2);
 }

 Test('test');

Lub

 function Test(argument1, argument2) {
      argument2 = argument2 || 'blah';

      alert(argument2);
 }

 Test('test');

O ile mogę stwierdzić, oba skutkują tym samym, ale pierwszego użyłem tylko w produkcji.

Kolejna opcja, o której wspomniał Tom :

function Test(argument1, argument2) {
    if(argument2 === null) {
        argument2 = 'blah';
    }

    alert(argument2);
}

Zgodnie z komentarzem Juana lepiej byłoby zmienić sugestię Toma na:

function Test(argument1, argument2) {
    if(argument2 === undefined) {
        argument2 = 'blah';
    }

    alert(argument2);
}

Istnieje kilka różnych sposobów sprawdzenia, czy argument został przekazany do funkcji. Oprócz dwóch wymienionych w (oryginalnym) pytaniu - sprawdzanie arguments.lengthlub używanie ||operatora do podania wartości domyślnych - można również jawnie sprawdzić argumenty za undefinedpośrednictwem argument2 === undefinedlub typeof argument2 === 'undefined'jeśli jeden jest paranoiczny (patrz komentarze).

Korzystanie z ||operatorem stał się standardową praktyką - wszystkie fajne dzieciaki to zrobić - ale bądź ostrożny: Wartość domyślna zostanie wyzwolony jeśli analizuje schemat argument false, czyli może to być rzeczywiście undefined, null, false, 0, ''(lub czegokolwiek innego, dla którego Boolean(...)powraca false).

Pytanie brzmi, kiedy należy użyć, które sprawdzanie, ponieważ wszystkie dają nieco inne wyniki.

Sprawdzanie arguments.lengthwykazuje zachowanie „najbardziej poprawne”, ale może nie być wykonalne, jeśli istnieje więcej niż jeden opcjonalny argument.

Test na undefinednastępny jest „najlepszy” - „kończy się niepowodzeniem” tylko wtedy, gdy funkcja jest jawnie wywoływana z undefinedwartością, która najprawdopodobniej powinna być traktowana tak samo, jak pominięcie argumentu.

Użycie ||operatora może spowodować użycie wartości domyślnej, nawet jeśli podany zostanie prawidłowy argument. Z drugiej strony jego zachowanie może być pożądane.

Podsumowując: używaj go tylko wtedy, gdy wiesz, co robisz!

Moim zdaniem użycie ||jest również dobrym rozwiązaniem, jeśli istnieje więcej niż jeden opcjonalny argument i nie chcemy przekazać literału obiektu jako obejścia nazwanych parametrów.

Inny fajny sposób na arguments.lengthpodanie wartości domyślnych jest możliwy poprzez przejrzenie etykiet instrukcji switch:

function test(requiredArg, optionalArg1, optionalArg2, optionalArg3) {
    switch(arguments.length) {
        case 1: optionalArg1 = 'default1';
        case 2: optionalArg2 = 'default2';
        case 3: optionalArg3 = 'default3';
        case 4: break;
        default: throw new Error('illegal argument count')
    }
    // do stuff
}

Ma to tę wadę, że intencja programisty nie jest (wizualnie) oczywista i używa „magicznych liczb”; dlatego może być podatny na błędy.

Jeśli używasz jQuery, jedną z przyjemnych opcji (szczególnie w skomplikowanych sytuacjach) jest użycie metody rozszerzającej jQuery .

function foo(options) {

    default_options = {
        timeout : 1000,
        callback : function(){},
        some_number : 50,
        some_text : "hello world"
    };

    options = $.extend({}, default_options, options);
}

Jeśli wywołasz funkcję, to w ten sposób:

foo({timeout : 500});

Zmienna opcji wyglądałaby wtedy:

{
    timeout : 500,
    callback : function(){},
    some_number : 50,
    some_text : "hello world"
};

To jeden z niewielu przypadków, w których znajduję test:

if(! argument2) {  

}

działa całkiem nieźle i niesie prawidłową implikację składniową.

(Przy jednoczesnym ograniczeniu, że nie pozwolę na uzasadnioną wartość zerową, dla argument2której ma inne znaczenie; ale byłoby to naprawdę mylące).

EDYTOWAĆ:

To jest naprawdę dobry przykład różnicy stylistycznej między językami luźno i mocno pisanymi; oraz opcja stylistyczna, którą zapewnia javascript w pikach.

Moje osobiste preferencje (bez krytyki w stosunku do innych preferencji) to minimalizm. Im mniej kod ma do powiedzenia, dopóki jestem spójny i zwięzły, tym mniej ktoś inny musi zrozumieć, aby poprawnie wywnioskować moje znaczenie.

Jedną z implikacji tej preferencji jest to, że nie chcę - nie uważam za użyteczne - układania wielu testów zależności typu. Zamiast tego staram się, aby kod oznaczał to, jak wygląda; i testuj tylko pod kątem tego, co naprawdę będę musiał przetestować.

Jednym z zaostrzeń, które dostrzegam w kodzie innych ludzi, jest potrzeba ustalenia, czy w szerszym kontekście oczekują, czy rzeczywiście trafią na przypadki, w których testują. Lub jeśli próbują przetestować wszystko, co możliwe, na szansę, że nie przewidują wystarczająco kontekstu. Co oznacza, że ​​w końcu muszę je dokładnie wyśledzić w obu kierunkach, zanim będę mógł cokolwiek zmienić lub zmodyfikować. Myślę, że istnieje spora szansa, że ​​mogliby przeprowadzić te różne testy, ponieważ przewidzieli okoliczności, w których będą potrzebne (i które zwykle nie są dla mnie oczywiste).

(Uważam, że to poważna wada w sposobie, w jaki ci ludzie używają dynamicznych języków. Zbyt często ludzie nie chcą rezygnować ze wszystkich testów statycznych i kończą je udawanie).

Widziałem to najbardziej rażąco w porównaniu obszernego kodu ActionScript 3 z eleganckim kodem javascript. AS3 może być 3 lub 4 razy większy od js, a podejrzewam, że niezawodność przynajmniej nie jest lepsza, tylko z powodu liczby (3-4X) podjętych decyzji w sprawie kodowania.

Jak mówisz, Shog9, YMMV. :RE

Istnieją znaczne różnice. Ustawmy kilka przypadków testowych:

var unused; // value will be undefined
Test("test1", "some value");
Test("test2");
Test("test3", unused);
Test("test4", null);
Test("test5", 0);
Test("test6", "");

Przy pierwszej opisanej metodzie tylko drugi test użyje wartości domyślnej. Druga metoda będzie domyślnie wszystko ale pierwszy (jak JS przekonwertuje undefined, null, 0, i ""do wartości logicznej false. A jeśli było użyć metody Toma, tylko czwarta próba użyje domyślnego!

Wybór metody zależy od zamierzonego zachowania. Jeśli wartości inne niż undefinedsą dozwolone argument2, prawdopodobnie będziesz potrzebować pewnej odmiany pierwszego; jeśli pożądana jest niezerowa, niepusta, niepusta wartość, wówczas druga metoda jest idealna - w rzeczywistości często stosuje się ją do szybkiego wyeliminowania tak szerokiego zakresu wartości z rozważań.

url = url === undefined ? location.href : url;

W ES6 (ES2015) możesz użyć parametrów domyślnych

function Test(arg1 = 'Hello', arg2 = 'World!'){
  alert(arg1 + ' ' +arg2);
}

Test('Hello', 'World!'); // Hello World!
Test('Hello'); // Hello World!
Test(); // Hello World!

Przepraszam, wciąż nie mogę komentować, więc aby odpowiedzieć na odpowiedź Toma ... W javascript (undefined! = Null) == false W rzeczywistości ta funkcja nie będzie działać z „null”, powinieneś użyć „undefined”

Dlaczego nie skorzystać z !!operatora? Ten operator, umieszczony przed zmienną, zamienia ją na wartość logiczną (o ile dobrze rozumiem), więc !!undefinedi !!null(a nawet !!NaN, co może być całkiem interesujące) powróci false.

Oto przykład:

function foo(bar){
    console.log(!!bar);
}

foo("hey") //=> will log true

foo() //=> will log false

Podejście do wykrywania argumentów może być wygodne, wywołując funkcję za pomocą obiektu właściwości opcjonalnych:

function foo(options) {
    var config = { // defaults
        list: 'string value',
        of: [a, b, c],
        optional: {x: y},
        objects: function(param){
           // do stuff here
        }
    }; 
    if(options !== undefined){
        for (i in config) {
            if (config.hasOwnProperty(i)){
                if (options[i] !== undefined) { config[i] = options[i]; }
            }
        }
    }
}

Istnieje również trudny sposób stwierdzenia, czy parametr jest przekazywany do funkcji, czy nie . Spójrz na poniższy przykład:

this.setCurrent = function(value) {
  this.current = value || 0;
};

Oznacza to, że jeśli wartość parametru valuenie występuje / nie została przekazana - ustaw ją na 0.

Całkiem fajne, huh!

Czasami możesz również chcieć sprawdzić typ, szczególnie jeśli używasz funkcji jako getter i setter. Następujący kod to ES6 (nie będzie działał w EcmaScript 5 lub starszym):

class PrivateTest {
    constructor(aNumber) {
        let _aNumber = aNumber;

        //Privileged setter/getter with access to private _number:
        this.aNumber = function(value) {
            if (value !== undefined && (typeof value === typeof _aNumber)) {
                _aNumber = value;
            }
            else {
                return _aNumber;
            }
        }
    }
}

function example(arg) {
  var argumentID = '0'; //1,2,3,4...whatever
  if (argumentID in arguments === false) {
    console.log(`the argument with id ${argumentID} was not passed to the function`);
  }
}

Ponieważ tablice dziedziczą Object.prototype. Zastanów się ⇑, aby uczynić świat lepszym.

fnCalledFunction (Param1, Param2, window.YourOptionalParameter)

Jeśli powyższa funkcja jest wywoływana z wielu miejsc i masz pewność, że pierwsze 2 parametry są przekazywane z każdego miejsca, ale nie jesteś pewien co do trzeciego parametru, możesz użyć okna

Window.param3 obsłuży, jeśli nie jest zdefiniowane w metodzie wywołującej.