对不起，我还不能评论，所以回答汤姆的回答… 在javascript中(undefined != null) == false 事实上，该函数不能使用“null”，你应该使用“undefined”

为什么不用!!运营商吗?这个运算符，放在变量之前，把它变成一个布尔值(如果我理解得很好)，所以!!未定义和!!Null(甚至!!)NaN，这很有趣)将返回false。

这里有一个例子:

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

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

foo() //=> will log false

有几种不同的方法来检查参数是否传递给了函数。除了你在你的(原始的)问题检查论点中提到的两个。长度或使用||操作符提供默认值-如果你是偏执狂，你也可以通过argument2 === undefined或typeof argument2 === 'undefined'显式检查参数是否为undefined(见注释)。

使用||操作符已经成为标准实践——所有很酷的孩子都这么做——但要小心:如果参数的计算结果为false，则会触发默认值，这意味着它实际上可能是未定义的、null、false、0，”(或任何Boolean(…)返回false的值)。

所以问题是什么时候使用哪种检查，因为它们产生的结果都略有不同。

检查参数。长度表现出“最正确”的行为，但如果有多个可选参数，它可能就不可行了。

对于undefined的测试是下一个“最好”的测试——只有当函数显式地使用一个未定义的值调用时，它才会“失败”，这很可能与省略实参一样。

使用||操作符可能会触发使用默认值，即使提供了有效参数。另一方面，它的行为实际上可能是需要的。

总结一下:只有在你知道自己在做什么的时候才使用它!

在我看来，使用||也是一种方法，如果有多个可选参数，并且不想传递一个对象文字作为命名参数的变通方法。

另一种使用参数提供默认值的好方法。长度可以通过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
}

这样做的缺点是，程序员的意图(在视觉上)并不明显，而是使用“神奇的数字”;因此，它可能容易出错。

对不起，我还不能评论，所以回答汤姆的回答… 在javascript中(undefined != null) == false 事实上，该函数不能使用“null”，你应该使用“undefined”

通过调用带有可选属性的Object来调用函数，可以方便地检测参数:

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

这是我发现的少数几个测试案例之一:

if(! argument2) {  

}

工作得很好，并且在语法上具有正确的含义。

(同时限制我不允许argument2有一个合法的空值，它有一些其他的含义;但这真的会让人困惑。)

编辑:

这是一个很好的例子，说明了松散类型语言和强类型语言之间的风格差异;这是javascript提供的一种风格选择。

我个人的偏好是极简主义(对其他偏好没有批评)。只要我是一致和简洁的，代码需要表达的越少，其他人就需要理解的越少，从而正确地推断出我的意思。

这种偏好的一个暗示是，我不想——也不认为它有用——堆积一堆类型依赖的测试。相反，我试图让代码的意思像它看起来的那样;只测试我真正需要测试的东西。

One of the aggravations I find in some other peoples' code is needing to figure out whether or not they expect, in the larger context, to actually run into the cases they are testing for. Or if they are trying to test for everything possible, on the chance that they don't anticipate the context completely enough. Which means I end up needing to track them down exhaustively in both directions before I can confidently refactor or modify anything. I figure that there's a good chance they might have put those various tests in place because they foresaw circumstances where they would be needed (and which usually aren't apparent to me).

(我认为这是这些人使用动态语言的一个严重缺点。人们经常不愿意放弃所有的静态测试，最终以假装测试而告终。)

在比较全面的ActionScript 3代码和优雅的javascript代码时，我最清楚地看到了这一点。AS3可以是js的3到4倍，我怀疑可靠性至少不会更好，只是因为所做的编码决策的数量(3-4倍)。

如你所说，Shog9, YMMV。: D