【发布时间】:2015-02-12 23:21:03
【问题描述】:
是否有适当的语法来记录可选的 JavaScript 参数,其中可选参数位于函数头的中间(想想 jQuery、Gulp 等)
我已经以标准方式记录了该功能,并且效果很好。问题是当我尝试将第二个参数设置为最后一个变量(在未使用可选参数的情况下)时,我的 IDE 会感到困惑。
例子:
/**
* @param {number} a_num
* @param {string} [a_str='']
* @param {{}} a_obj
*/
function (a_num, a_str, a_obj) {
if (!a_obj) a_obj = a_str; // doesn't want me to save a string to an object.
a_str = '';
// more stuff
}
如果重要的话,我使用的是 JetBrains 的 PHPStorm,它主要使用 Google Closure 文档样式。虽然我正在寻找更通用的最佳实践方法。
我怀疑我可以做一些丑陋的事情,比如:
/**
* @param {number} a_num
* @param {string|{}} a_str
* @param {{}} [a_obj=null]
*/
但这并不能像我想的那样准确地描述这种情况。我希望,因为这正在成为一种常见的结构,所以有一些东西可以正确处理。
【问题讨论】:
-
我有两张反对票,还有一次因为不清楚而试图关闭。我知道函数头中间的可选参数在大多数语言中是禁忌(或完全不可能),但在 JavaScript 中它是一种有效且经常使用的模式,所以我认为这是一个有效的问题。至于不清楚,如果有人可以发表评论让我知道不清楚的地方,我很乐意更新这个问题。谢谢。
-
你可以在 javascript 中做很多事情,但仅仅因为语言允许它并不意味着它是好的做法。例如,javascript 允许使用全局变量,而许多语言则不允许,这并不意味着在 JS 中使用大量全局变量是个好主意。
-
我已经删除了我的答案,因为它并没有真正回答你的问题,但我在这里添加它作为评论,因为我认为它仍然是对话的相关部分:我认为把参数列表中间的可选参数。它可能会增加 API 用户的困惑。而是考虑将可选参数放在参数的末尾,或者传入一个选项对象而不是参数列表。
-
@bhspencer:很公平,我也不完全不同意你的观点。我认为它有助于整体清晰的一个有效用例是当最后一个参数是回调时,它允许更清晰、更容易读取传入的匿名函数。谢谢。
-
@bhspencer 我也同意这一点。但是,匿名回调有一些有效的时间和地点。我正在考虑的特定实例,也恰好是我问这个问题的函数的用例,是用于 gulp 任务中的函数。 Gulp 任务通常很简单,并且该函数永远不需要重用。在这种情况下使用回调可以提高可读性。
标签: javascript google-closure jsdoc jsdoc3