为什么Google的Closure Compiler会留下一些不必要的空格或换行符？ [英] Why does Google's Closure Compiler leave a few unnecessary spaces or line breaks?

问题描述

我注意到每次使用 Google的Closure Compiler Service 时，都会留下一些页面右侧显示的编译代码中不必要的空格。这些对应于已编译代码的托管版本中的换行符。

I've noticed that every time I use Google's Closure Compiler Service, it leaves a few unnecessary spaces in the compiled code presented on the right-hand side of the page. These correspond to line breaks in the hosted version of the compiled code.

例如（注意换行符，每个换行符似乎都是不必要的）：

For example (note the line breaks, each of which seems unnecessary):

http://troy.onespot.com/static/ stack_overflow / closure_spaces.js

到目前为止，我刚刚手动删除它们，但我很好奇他们为什么会在那里。是否限制代码托管版本的行长度使其更具可读性？
编译器是否足够智能可以有意留下或插入那些有意识地最大化GZIP压缩工作？

To date, I've just been removing them manually, but I'm curious why they're there. Is it to limit the line length of the hosted version of the code to make it more readable? Could the compiler be smart enough to leave or insert those intentionally to maximize GZIP compression efforts?

我知道它们对文件大小有轻微的影响，但是为了缩小源脚本中的每个最后一个字节而付出了太多的努力，这是违反直觉的原因。

I know that they have a trivial effect on the file size, but with so much effort going into minifying every last byte in the source script, it's counterintuitive why they're there.

推荐答案

引用关闭编译器常见问题解答：

为什么编译脚本中有随机换行？

Closure Compiler故意添加行每500个字符左右打破一次。防火墙和代理有时会损坏或忽略具有很长行的大型JavaScript文件。每500个字符添加换行符可以防止出现此问题。删除换行符对脚本的语义没有影响。对代码大小的影响很小，并且编译器优化换行符位置，以便在压缩文件时代码大小损失更小。

The Closure Compiler intentionally adds line breaks every 500 characters or so. Firewalls and proxies sometimes corrupt or ignore large JavaScript files with very long lines. Adding line breaks every 500 characters prevents this problem. Removing the line breaks has no effect on a script's semantics. The impact on code size is small, and the Compiler optimizes line break placement so that the code size penalty is even smaller when files are gzipped.

<你知道它很聪明！ ：）

You knew it was smart! :)

这篇关于为什么Google的Closure Compiler会留下一些不必要的空格或换行符？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！