Qual a melhor forma de determinar se um argumento não é enviado para a função JavaScript

Eu já vi dois métodos para determinar se um argumento foi passado para uma função JavaScript. Gostaria de saber se um método é melhor que o outro ou se é apenas ruim de usar?

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

      alert(argument2);
 }

 Test('test');

Ou

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

      alert(argument2);
 }

 Test('test');

Tanto quanto posso dizer, ambos resultam na mesma coisa, mas eu só usei o primeiro antes na produção.

Outra opção, como mencionado por Tom :

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

    alert(argument2);
}

Conforme o comentário de Juan, seria melhor mudar a sugestão de Tom para:

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

    alert(argument2);
}

Existem várias maneiras diferentes de verificar se um argumento foi passado para uma função. Além das duas que você mencionou na sua pergunta (original) - verificando arguments.lengthou usando o ||operador para fornecer valores padrão - também é possível verificar explicitamente os argumentos por undefinedvia argument2 === undefinedou typeof argument2 === 'undefined'se é paranóico (consulte os comentários).

Usando o ||operador tornou-se prática padrão - todos os miúdos legal fazê-lo - mas tenha cuidado: o valor padrão será acionado se os avalia argumento para false, o que significa que pode realmente ser undefined, null, false, 0, ''(ou qualquer outra coisa para a qual Boolean(...)retorna false).

Portanto, a questão é quando usar essa verificação, pois todas elas produzem resultados ligeiramente diferentes.

A verificação arguments.lengthexibe o comportamento 'mais correto', mas pode não ser possível se houver mais de um argumento opcional.

O teste para undefinedé o próximo 'melhor' - apenas 'falha' se a função for chamada explicitamente com um undefinedvalor, que provavelmente deve ser tratado da mesma maneira que omitir o argumento.

O uso do ||operador pode acionar o uso do valor padrão, mesmo que um argumento válido seja fornecido. Por outro lado, seu comportamento pode realmente ser desejado.

Para resumir: use-o apenas se você souber o que está fazendo!

Na minha opinião, usar ||também é o caminho a percorrer se houver mais de um argumento opcional e não se desejar passar um literal de objeto como uma solução alternativa para os parâmetros nomeados.

Outra boa maneira de fornecer valores padrão arguments.lengthé possível através dos rótulos de uma instrução 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
}

Isso tem o lado negativo de que a intenção do programador não é (visualmente) óbvia e usa 'números mágicos'; é, portanto, possivelmente propenso a erros.

Se você estiver usando o jQuery, uma opção interessante (especialmente para situações complicadas) é usar o método de extensão do jQuery .

function foo(options) {

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

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

Se você chamar a função, faça o seguinte:

foo({timeout : 500});

A variável options seria então:

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

Este é um dos poucos casos em que encontro o teste:

if(! argument2) {  

}

funciona muito bem e carrega a implicação correta sintaticamente.

(Com a restrição simultânea de que eu não permitiria um valor nulo legítimo para o argument2qual tenha algum outro significado; mas isso seria realmente confuso.)

EDITAR:

Este é realmente um bom exemplo de diferença estilística entre linguagens de tipo fraco e forte; e uma opção estilística que o javascript oferece em espadas.

Minha preferência pessoal (sem críticas para outras preferências) é minimalismo. Quanto menos o código tiver a dizer, desde que eu seja consistente e conciso, menos alguém precisará compreender para inferir corretamente meu significado.

Uma implicação dessa preferência é que eu não quero - não acho útil - acumular vários testes de dependência de tipo. Em vez disso, tento fazer com que o código signifique o que parece; e teste apenas o que realmente preciso testar.

Um dos agravos que encontro no código de outras pessoas está precisando descobrir se eles esperam ou não, em um contexto mais amplo, realmente encontrar os casos pelos quais estão testando. Ou se eles estão tentando testar o máximo possível, com a chance de não antecipar o contexto completamente o suficiente. O que significa que acabo precisando rastreá-los exaustivamente nas duas direções antes de poder refatorar ou modificar qualquer coisa com confiança. Acho que há uma boa chance de que eles possam ter implementado esses vários testes porque previram circunstâncias onde seriam necessárias (e que geralmente não são aparentes para mim).

(Considero isso uma desvantagem séria na maneira como essas pessoas usam linguagens dinâmicas. Muitas vezes as pessoas não querem desistir de todos os testes estáticos e acabam fingindo.)

Eu já vi isso de maneira flagrante ao comparar o código abrangente do ActionScript 3 com o elegante código javascript. O AS3 pode ser 3 ou 4 vezes a maior parte dos js, e a confiabilidade que eu suspeito é pelo menos não melhor, apenas por causa do número (3-4X) de decisões de codificação que foram tomadas.

Como você diz, Shog9, YMMV. : D

Existem diferenças significativas. Vamos configurar alguns casos de teste:

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

Com o primeiro método que você descreve, apenas o segundo teste usa o valor padrão. O segundo método será o padrão todos, mas o primeiro (como JS irá converter undefined, null, 0, e ""para o boolean false. E se você fosse usar o método de Tom, apenas o quarto teste usará o padrão!

O método escolhido depende realmente do comportamento pretendido. Se outros valores undefinedsão permitidos argument2, provavelmente você desejará alguma variação no primeiro; se um valor diferente de zero, nulo e não vazio é desejado, o segundo método é ideal - na verdade, ele é frequentemente usado para eliminar rapidamente uma ampla variedade de valores da consideração.

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

No ES6 (ES2015), você pode usar Parâmetros padrão

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

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

Sinto muito, ainda não posso comentar, então, para responder à resposta de Tom ... Em javascript (indefinido! = Null) == false Na verdade, essa função não funcionará com "null", você deve usar "undefined"

Por que não usar o !!operador? Esse operador, colocado antes da variável, transforma-o em um booleano (se eu entendi bem), então !!undefinede !!null(e até !!NaN, o que pode ser bem interessante) retornará false.

Aqui está um exemplo:

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

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

foo() //=> will log false

Pode ser conveniente abordar a detecção de argumentos, evocando sua função com um Objeto de propriedades opcionais:

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

Também há uma maneira complicada de descobrir se um parâmetro é passado para uma função ou não . Veja o exemplo abaixo:

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

Isso necessário significa que, se o valor de valuenão estiver presente / passado - defina-o como 0.

Muito legal né!

Algumas vezes você também pode querer verificar o tipo, especialmente se estiver usando a função como getter e setter. O código a seguir é ES6 (não será executado no EcmaScript 5 ou mais antigo):

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

Porque matrizes são herdadas de Object.prototype. Considere ⇑ para tornar o mundo melhor.

fnCalledFunction (Param1, Param2, window.YourOptionalParameter)

Se a função acima for chamada de muitos lugares e você tiver certeza de que os 2 primeiros parâmetros foram passados ​​de todos os locais, mas não tiver certeza do terceiro parâmetro, poderá usar a janela.

window.param3 tratará se não for definido no método de chamada.