Google Closureコンパイラで実行したJavaScriptファイルがあり、名前on
がza
に変更されました。これは、長さの観点からは明らかに効率的ではありません。それが実際に(おそらく使用されている文字のために)より効率的である理由はありますか、それとも単にいくつかのランダムな文字ですか?
たとえば、Gzipza
圧縮の場合よりも圧縮可能である可能性がありますが、ランダムな文字が2、3文字ある可能性があります。on
Google Closureコンパイラで実行したJavaScriptファイルがあり、名前on
がza
に変更されました。これは、長さの観点からは明らかに効率的ではありません。それが実際に(おそらく使用されている文字のために)より効率的である理由はありますか、それとも単にいくつかのランダムな文字ですか?
たとえば、Gzipza
圧縮の場合よりも圧縮可能である可能性がありますが、ランダムな文字が2、3文字ある可能性があります。on
http://closure-compiler.appspot.com/homeで遊んだ後、以前の名前に関係なく、コンパイラが変数の名前を変更し始めたようです。「a」にとどまり、「b」などを通過します...変数名の現在の長さは気にしていないようですが、全体のサイズが以前と同じかそれよりも小さいことを確認します。高度な最適化設定を使用すると、変数がコードからリファクタリングされる場合があります。
コンパイラーに変数の命名を処理させることで、それらが互いに競合しないことが保証されます。既存の変数名を保持しようとした場合、それを個別に追跡し、比較するリストを維持する必要があります。
コードを縮小するもう 1 つの利点は、コード ベースを難読化できることです。確かに誰かが本当に望むならそれを理解することができますが、変数名をプログラム的にすることで意味を理解するのが難しくなります.
組み合わせて縮小したコードで本当にデバッグしたい場合は、Google Chrome Canary http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/のソース マップ機能を調べることをお勧めします。
実際、より効率的である何らかの理由がありますか(おそらく使用されている文字のため)
いいえ。
それともランダムな数文字ですか?
かなり。私の知る限り、Closure Compiler(および他のJSミニファイアー)は、変数の名前を体系的に変更し、使用する文字を全体的に少なくすることを目標としており、既に名前が付けられているものを確認する必要はありません。