javascript - 首先声明变量函数的目的是什么?(两次声明变量)

Oli*_*ams 4 javascript minify no-op

这是我遇到的代码:

    var c = function() {},
        c = {
            autoSelectFirst: !1,
            appendTo: "body",
            serviceUrl: null,
            lookup: null,
            .. etc..
            lookupFilter: function(a, b, c) {
                return -1 !== a.value.toLowerCase().indexOf(c)
            },
            .. etc..
        };
Run Code Online (Sandbox Code Playgroud)

为什么c首先声明为空函数然后重新声明为对象?那不就是覆盖函数声明吗?我想这是一个基本的JS结构.

小智 7

我在网上找到了有问题的文件,结果证明这是有充分理由的.

首先,应该注意的是,问题中的代码来自缩进的缩小源.

这是代码的一大块:

var c=function(){},c={autoSelectFirst:!1,appendTo:"body",serviceUrl:null,lookup:null,
onSelect:null,width:"auto",minChars:1,maxHeight:300,deferRequestBy:0,params:{},
formatResult:g.formatResult,delimiter:null,zIndex:9999,type:"GET",noCache:!1,
onSearchStart:c,onSearchComplete:c,onSearchError:c,
// -----------^------------------^---------------^
Run Code Online (Sandbox Code Playgroud)

所以这是问题中的代码,但更多一点.需要注意的重要一点是,变量c用于创建对象文字,用于onSearchStart:c,onSearchComplete:c,onSearchError:c,.

那么c在对象中分配哪个值?因为对象仍处于创建过程中,这意味着c仍然引用该函数,因此像onSearchStart似乎是事件处理程序的属性将空函数作为默认值.

这更有意义.

为了验证,我还找到了原始的,未经证实的来源.这是相关的代码:

//   v---originally it's called `noop`
var noop = function () { },
    that = this,
    defaults = {
        autoSelectFirst: false,
        appendTo: 'body',
        serviceUrl: null,
        lookup: null,
        onSelect: null,
        width: 'auto',
        minChars: 1,
        maxHeight: 300,
        deferRequestBy: 0,
        params: {},
        formatResult: YithAutocomplete.formatResult,
        delimiter: null,
        zIndex: 9999,
        type: 'GET',
        noCache: false,
        onSearchStart: noop,    // <---here it's being used
        onSearchComplete: noop, // <---here it's being used
        onSearchError: noop,    // <---here it's being used
Run Code Online (Sandbox Code Playgroud)

因此现在更清楚的是noop,它通常代表无操作,具有自己的名称,并且确实用于正在其下方创建的对象中.此外,这是整个文件中唯一使用的地方noop.

显然,minifier足够聪明,可以看到最初调用的变量noop不再被使用,因此可以自由地为该对象重用该变量名.一个令人印象深刻的代码分析,IMO.

  • 惊人的发现和分析. (2认同)
  • 我应该补充一点,我认为这是一个反模式,实际上手动编写这样的代码.对于正在阅读代码的人来说,这是非常误导并且不会立即显而易见.创建不适合人类消费的代码的代码生成器被允许进行不可读的优化技巧,但人类不应该编写这样的代码供其他人阅读.对于人类可读的代码,这样的优化并不比使后来的代码易于理解和维护代码更有优势. (2认同)