【问题标题】:Should We Use Long-Name Or Short-Name in JavaScript Coding?我们应该在 JavaScript 编码中使用长名称还是短名称?
【发布时间】:2009-03-22 13:35:23
【问题描述】:

在我的工作组中有一个关于 JavaScript 编码的讨论。有些人认为我们应该使用长名称以获得更好的可读性;其他人认为短名称应该有利于相同的在线位。

一般来说,它是关于编码约定的。一方面认为“fAutoAdjustWidth”等标识符是可以的,而另一些则更喜欢“fAtAjtW”。

那么,更好的方法是什么?我们是否应该为了性能而牺牲可读性?

【问题讨论】:

  • 我认为你应该抓住那些诚实地认为 fAtAjtW 更好的人,让他们交出他们的开发者徽章。

标签: javascript performance coding-style readability


【解决方案1】:

使其可读,如果您觉得生成的 JS 文件太大,请在部署生产版本之前使用众多 JS 压缩器之一,同时维护具有长名称的开发版本。

顺便说一句。如果您真的担心带宽,请使用mod_deflate

【讨论】:

    【解决方案2】:

    如果您担心线路上的位,您可以随时在您的代码上运行压缩程序。然后您可以使用长名称进行开发,并且可以使用更小的文件发布 具有同等功能。 Yahoo YUI Compressor 看起来像是在进行空格压缩和令牌压缩。

    【讨论】:

      【解决方案3】:

      这些人是否主张不在他们的代码中编写 cmets?变量名称要完全清晰且具有描述性。

      【讨论】:

        【解决方案4】:

        而其他人更喜欢“fAtAjtW”

        即使“bits-on-wire”是个问题(事实并非如此),这样的命名约定也会使代码在项目工作的第一周后完全无法维护。

        阅读代码几乎是不可能的,在编写代码时,人们必须不断思考诸如“'fAutoAdjustWidth' 缩写为 'fAtAjtW' 还是 'fAutAtW'?”之类的问题。在编写代码时要付出巨大的精神负担,这将导致生产力大大降低。

        最重要的是,在 Javascript 中,每个输入错误的名称都会获得一个新变量,这一事实加剧了这个问题!

        【讨论】:

          【解决方案5】:

          也许担心的不是线路上的位,而是读取和重新/查看代码的开销。

          我倾向于在函数中使用短名称,并尽可能使函数名称尽可能长,但在不失去有用意义的情况下尽可能短。

          毫无疑问,这是一种权衡。这取决于您是希望您的代码类似于自然语言还是更加隐含和紧凑。

          一些前缀变量名称以将上下文信息注入其中。我说,如果有必要,IDE 应该提供注入功能,例如通过上下文符号在代码上进行可视化覆盖。

          Visual Studio 的下一个版本将通过深入到编辑器本身的细粒度可扩展性机制使此类注释操作变得更加容易。不过,我还没有使用 Visual Studio 来编辑 Javascript。

          我现在明白了,您关心的确实是空间权衡。这永远不应该成为问题。总是总是喜欢可读性而不是在线上的位,尤其是。正如其他评论员所指出的那样,因为存在压缩。

          我唯一要补充的是上面的内容,即有时使用紧凑的名称比过长的名称更容易理解。但是,要正确命名短名称更难。根据我的经验,长名称更容易、更快捷。

          短名称的原因不应该只是数据压缩认知效率。有效的是个人。

          【讨论】:

            【解决方案6】:

            使用大变量名,因为它们对程序员有帮助。

            为了节省网络数据,请在将 Javascript 部署到生产服务器之前将其缩小。 Dean Edwards' packer 有一个压缩变量名的选项,这对你来说似乎是两全其美。

            【讨论】:

              【解决方案7】:

              使用足以很好地描述变量和函数的长名称。

              许多人需要短名称的原因之一是为了使文件更小,但您可以在在线上传时通过工具来做到这一点。

              【讨论】:

                【解决方案8】:

                我强烈建议不要使用短标识符。仅阅读您的示例就可以看出,当使用 fAtAjtW 之类的名称时,突然需要更多文档。在某些时候,它会变得几乎无法维护,这只是为了节省一些要传输的字节。

                如果考虑“短”名称的唯一原因是使生成的脚本更小,从而节省一些带宽,我建议使用 gzip 压缩,这将为您节省超过几个字节的标识符。

                【讨论】:

                  【解决方案9】:

                  一方认为“fAutoAdjustWidth”等标识符是可以的,而另一方则更喜欢“fAtAjtW”。

                  ‘fAtAjtW’是一种无法阅读、无法打字的恐怖。说真的,有人喜欢吗?好笑且无法记住 — 是“AtAjt”还是“AutAdj”...?

                  ‘autoAdjustWidth’将是一个合适的完整属性名称。 (我根本不相信 'f' 前缀表示法,但这是另一个问题。)有时你想要一个短命变量的名字很短(例如,一个小循环中的临时变量),在这种情况下我'会亲自去'var aaw'而不是上面的噩梦。

                  至于性能,没有区别。 JavaScript 不关心变量名称的长度,并且假设您在将脚本压缩到浏览器的过程中,压缩将消除较短名称的任何传输优势。

                  【讨论】:

                    【解决方案10】:

                    认为“fAtAjtW”更可取的人在他们的编程中使用了某种药理学方法。 fAutoAdjustWidth 非常精细,非常谨慎。 Javascript 库不使用 fAtAjtW 之类的名称是有原因的。如果您担心尺寸,那么您的担心可能是错误的。但是,我建议使用某种缩小器。但是,也就是说,不要使用太长的时间;可能超过 25-30 个字符的任何内容都有点远。

                    【讨论】:

                      【解决方案11】:

                      在不影响代码可读性的情况下使用较小的名称。更大的名字很好,但尽量只在真正让自己和他人更容易理解的地方使用它们。最后(如其他答案所述)minify 您的代码,和/或打开某种服务器压缩机制,例如 apache 的 mod_gzip 或 mod_deflate 以减少流经线路的位数。

                      话虽如此,我会优先考虑可读性而不是变量名的紧凑性。

                      【讨论】:

                        【解决方案12】:

                        描述性的长名称。

                        并尝试使方法尽可能独特。这有助于导航。如果您想查找某个特定方法的所有用法,那么您与另一个同名方法发生冲突的可能性就会降低。

                        现代 Javascript IDE 也可以进行方法重构(请参阅:http://blue-walrus.com/2013/08/review-javascript-ides/)。如果方法调用相同,这将非常困难。

                        【讨论】:

                          猜你喜欢
                          • 2020-08-02
                          • 1970-01-01
                          • 2020-05-23
                          • 1970-01-01
                          • 1970-01-01
                          • 1970-01-01
                          • 1970-01-01
                          • 2016-10-05
                          • 1970-01-01
                          相关资源
                          最近更新 更多