La mejor manera de determinar si un argumento no se envía a la función de JavaScript

Ahora he visto 2 métodos para determinar si se ha pasado un argumento a una función de JavaScript. Me pregunto si un método es mejor que el otro o si uno es malo de usar.

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

      alert(argument2);
 }

 Test('test');

O

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

      alert(argument2);
 }

 Test('test');

Por lo que puedo decir, ambos resultan en lo mismo, pero solo he usado el primero antes en producción.

Otra opción mencionada por Tom :

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

    alert(argument2);
}

Según el comentario de Juan, sería mejor cambiar la sugerencia de Tom para:

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

    alert(argument2);
}

Hay varias formas diferentes de verificar si se pasó un argumento a una función. Además de los dos que mencionó en su pregunta (original), verificando arguments.lengtho usando el ||operador para proporcionar valores predeterminados, uno también puede verificar explícitamente los argumentos para undefinedvía argument2 === undefinedotypeof argument2 === 'undefined' si uno es paranoico (ver comentarios).

Usando el ||operador ha convertido en una práctica estándar - todos los niños frescos lo hacen - pero tenga cuidado: El valor por defecto se activa si los argumentos evalúa a false, lo que significa que en realidad podría ser undefined, null, false, 0, ''(o cualquier otra cosa para la que Boolean(...)vuelvefalse ).

Entonces, la pregunta es cuándo usar qué verificación, ya que todas producen resultados ligeramente diferentes.

Comprobación arguments.length exhibe el comportamiento 'más correcto', pero podría no ser factible si hay más de un argumento opcional.

La prueba para undefinedes el próximo 'mejor': solo 'falla' si la función se llama explícitamente con unundefined valor, que probablemente debería tratarse de la misma manera que omitiendo el argumento.

El uso de la || operador puede desencadenar el uso del valor predeterminado incluso si se proporciona un argumento válido. Por otro lado, su comportamiento podría ser realmente deseado.

Para resumir: ¡Úselo solo si sabe lo que está haciendo!

En mi opinión, el uso ||también es el camino a seguir si hay más de un argumento opcional y uno no quiere pasar un objeto literal como solución para los parámetros con nombre.

Otra buena manera de proporcionar valores predeterminados usando arguments.lengthes posible cayendo a través de las etiquetas de una declaración de cambio:

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
}

Esto tiene el inconveniente de que la intención del programador no es (visualmente) obvia y utiliza 'números mágicos'; Por lo tanto, es posible que sea propenso a errores.

Si está usando jQuery, una opción que es buena (especialmente para situaciones complicadas) es usar el método extendido de jQuery .

function foo(options) {

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

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

Si llama a la función, entonces así:

foo({timeout : 500});

La variable de opciones sería entonces:

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

Este es uno de los pocos casos en los que encuentro la prueba:

if(! argument2) {  

}

funciona bastante bien y conlleva la implicación correcta sintácticamente.

(Con la restricción simultánea de que no permitiría un valor nulo legítimo para el argument2que tiene algún otro significado; pero eso sería realmente confuso).

EDITAR:

Este es un muy buen ejemplo de una diferencia estilística entre lenguajes poco tipados y fuertemente tipados; y una opción estilística que JavaScript ofrece en espadas.

Mi preferencia personal (sin críticas para otras preferencias) es el minimalismo. Cuanto menos tenga que decir el código, mientras sea coherente y conciso, menos tendrá que comprender alguien más para inferir correctamente mi significado.

Una implicación de esa preferencia es que no quiero, no me parece útil, acumular un montón de pruebas de dependencia de tipo. En cambio, trato de hacer que el código signifique lo que parece; y prueba solo para lo que realmente tendré que probar.

Una de las molestias que encuentro en el código de otras personas es saber si esperan o no, en un contexto más amplio, encontrarse con los casos que están probando. O si están tratando de probar todo lo posible, en la posibilidad de que no anticipen el contexto lo suficiente. Lo que significa que termino necesitando rastrearlos exhaustivamente en ambas direcciones antes de poder refactorizar o modificar cualquier cosa con confianza. Me imagino que hay una buena posibilidad de que hayan implementado esas diversas pruebas porque previeron circunstancias en las que serían necesarias (y que generalmente no son aparentes para mí).

(Considero que es una desventaja grave en la forma en que estas personas usan lenguajes dinámicos. Con demasiada frecuencia, las personas no quieren renunciar a todas las pruebas estáticas y terminan fingiendo).

He visto esto de manera más evidente al comparar el código completo de ActionScript 3 con el elegante código de JavaScript. El AS3 puede ser 3 o 4 veces el grueso del js, y la confiabilidad que sospecho no es al menos mejor, solo por la cantidad (3-4X) de decisiones de codificación que se tomaron.

Como dices, Shog9, YMMV. :RE

Hay diferencias significativas Configuremos algunos casos de prueba:

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

Con el primer método que describa, solo la segunda prueba usará el valor predeterminado. El segundo método por defecto todos excepto el primero (como JS convertirá undefined, null, 0, y ""en el booleano false. Y si usted fuera a utilizar el método de Tom, sólo la cuarta prueba usará el valor por defecto!

El método que elija realmente depende de su comportamiento previsto. Si undefinedse permiten valores distintos de argument2, probablemente querrá alguna variación en el primero; si se desea un valor no cero, no nulo, no vacío, entonces el segundo método es ideal; de hecho, a menudo se usa para eliminar rápidamente un rango tan amplio de valores de la consideración.

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

En ES6 (ES2015) puede usar parámetros predeterminados

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

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

Lo siento, todavía no puedo comentar, así que para responder la respuesta de Tom ... En javascript (undefined! = Null) == false De hecho, esa función no funcionará con "null", debe usar "undefined"

¿Por qué no usar el !!operador? Este operador, colocada antes de la variable, lo convierten a un valor lógico (si he entendido bien), por lo que !!undefinedy !!null(e incluso !!NaN, que puede ser muy interesante) devolverá false.

Aquí hay un ejemplo:

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

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

foo() //=> will log false

Puede ser conveniente abordar la detección de argumentos evocando su función con un Objeto de propiedades opcionales:

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

También hay una manera difícil de encontrar, si un parámetro se pasa a una función o no . Echa un vistazo al siguiente ejemplo:

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

Esto significa que si el valor de valueno está presente / pasado, configúrelo en 0.

Muy bien, ¿eh?

Algunas veces también es posible que desee verificar el tipo, especialmente si está utilizando la función como getter y setter. El siguiente código es ES6 (no se ejecutará en EcmaScript 5 o anterior):

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 las matrices heredan de Object.prototype. Considere ⇑ para mejorar el mundo.

fnCalledFunction (Param1, Param2, window.YourOptionalParameter)

Si la función anterior se llama desde muchos lugares y está seguro de que los primeros 2 parámetros se pasan desde todas partes, pero no está seguro sobre el tercer parámetro, puede usar la ventana.

window.param3 se encargará si no está definido desde el método de la persona que llama.