「Airbnb JavaScript Style Guide」の引数への再代入禁止ルール

Question

Airbnb JavaScript Style Guide

「Airbnb JavaScript Style Guide」では引数へ再代入しない規約になっています。

• Airbnb JavaScript スタイルガイド() { | javascript-style-guide

• 7.13 パラメータを再割り当てしない。eslint: no-param-reassign

Why? Reassigning parameters can lead to unexpected behavior, especially when accessing the arguments object. It can also cause optimization issues, especially in V8.

なぜ? 特に argumentsオブジェクトにアクセスするとき、パラメータを再割り当てすると予期しない動作をする可能性があります。

argumentsオブジェクトが破壊される (Sloppy Mode限定)

特に argumentsオブジェクトにアクセスするとき、パラメータを再割り当てすると予期しない動作をする可能性があります。

これはおそらく、Sloppy Modeで arguments オブジェクトの要素値を書き換えてしまう動作を表していると想像します。

// Sloppy Mode
function sloppy (a) {
  a += 2;
  console.log(a);               // 3
  console.log(arguments[0]);    // 3 (書き換えられてしまう)
}

// Strict Mode
function strict (a) {
  'use strict';
  a += 2;
  console.log(a);               // 3
  console.log(arguments[0]);    // 1 (書き換わらない)
}

sloppy(1);
strict(1);

(2019/02/09 16:34追記)
@maisumakun さんより、Strict Modeではarguments破壊されないという指摘を頂きましたので、コードを追記しました。

事象発生の条件は3つあります。

1. Sloppy Mode である (Strict Modeではない)
2. 引数 a を再代入する
3. arguments[0] を参照する

argumentsを破壊させるコードを書くメリット

そもそも、arguments破壊の条件を満たしたコードを書くメリットはあるのでしょうか。
私のコーディングスタイルでは、「引数名による参照」と「arguments[i]による参照」は二者択一であり、それぞれの引数に対してどちらで参照するかを予め決めておきます(参照法を一つにする事でシンプルに書ける為)。

• 第一引数 … 引数 a で参照する
• 第二引数以降 … arguments[i] で参照する

従って、条件2と条件3が同時に成立する事はなく、この事象が発生する可能性は0になります。

質問

Q1. argumentsの破壊条件を成立したコードを書くメリットはありますか。あるとしたら、どんなコードが考えられますか。

特にV8では最適化の問題も発生する可能性があります。

Q2. V8最適化問題の詳細をご存知の方は教えて下さい。
Q3. V8最適化問題は現行の最新版である「Google Chrome v72.0.3626.96」でも残存しているのでしょうか。

Answer 1

Q1. それが必要な状況にどんなコードが考えられますか。

...argsのようなspread付き引数を、対応していないブラウザのためにコンパイルした場合、arguments経由のアクセスとなります。そして、function foo(a, ...rest)のような引数の持たせ方だった場合、コンパイルすると

function foo(a) {
  for (var _len = arguments.length, rest = Array(_len > 1 ? _len - 1 : 0), _key = 1; _key < _len; _key++) {
    rest[_key - 1] = arguments[_key];
  }

}

のように、「aは配列から、restはargumentsから取得」という実行になります。

もっとも、再代入はargumentsのアクセスより後で起きるものなので、速度の影響は考えづらい面もあります。

Comments

[maisumakun]

BluebirdのProject Wikiに少し書かれたものが見つかりました。

https://github.com/petkaantonov/bluebird/wiki/Optimization-killers#3-managing-arguments

Strictモードでは影響しないものもあるようです。

[think49]

私の質問が不適切でしたので、質問文(Q1)を修正しました。

第二引数以降を可変引数にする為に、arguments を利用するコードは私も書いたことがあります。
しかし、この場合、第一引数を書き換えても、arguments[0] で第一引数を参照しないので、arguments破壊の影響を受けません。
破壊の影響を受ける為には、「引数 a を再代入する」「arguments[0] を参照する」が必要条件ですが、そのようなコードを書く意味はありますか、が Q1. の意図でした。

> Strictモードでは影響しないものもあるようです。
情報ありがとうございます。
Google Chrome 72.0.3626.96でStrict Modeではargumentsが破壊されない事を確認しましたので、質問文に追記しました。

Answer 2

なにを気にしてるのかイマイチわかりませんが、
ローカルのオブジェクトな限りなにをどうしようが自由です。

ルールというのはニンゲンが見てわかりやすくする、ってだけのはなしなんで、
あとは個々のニンゲンの気分の問題にしかならないので、ご自由にどうぞ。

Comments

[think49]

クローズドソース、自分一人でコーディングしている場合は、仰る通りだと思います。
最も、「V8における最適化の問題」は自分一人でも「どうでもいい問題」ではなさそうですが…。

[y_waiwai]

最適化の問題と言ってもせいぜい最適化されないぐらいのことなんで、まあいいんじゃないかと。
チームで開発する場合のコーディングルール的なものは、従わなければならない的なもんなんで、理由を聞いてもしようがない、とは思っとります

[think49]

規約は盲目的に守るものではなく、意図を理解して使うものと認識しています。
最適化問題については、最適化の有無による影響力の大きさによって捉え方が変わると思います。

[y_waiwai]

それがそのまま個々のニンゲンの気分によるものなので、あなたはそうすればよろしい。
そう考えないニンゲンもいるということで。

[think49]

そうですね。意見は人それぞれだと私も思います。

Answer 3

下記のJSPerfを作成し、私の手元のChrome、Firefox、Edge(いずれもWin10上で最新)で試しましたが、有意義な差は出ませんでした。

https://jsperf.com/param-reassign

Node.jsの古いバージョンでは差が出る可能性があるため次のようなコードを作りました。

const Benchmark = require('benchmark');

const reassign = () => {
  const f = foo => {
    foo = Number(foo);
    return foo * foo + foo;
  };
  const nums = [2, "3", [5]];
  const results = nums.map(f);
};

const no_reassign = () => {
  const f = foo => {
    const bar = Number(foo);
    return bar * bar + bar;
  };
  const nums = [2, "3", [5]];
  const results = nums.map(f);
};

const suite = new Benchmark.Suite;

suite
.add('Reassignment', reassign)
.add('No Reassignment', no_reassign)
.on('cycle', event => console.log(String(event.target)))
.run({ 'async': true });

WSL上のUbuntu 18.04 LTSでNode.js 6.16.0, 8.15.0, 10.15.1, 11.9.0で上記を試しましたが、こちらも有意義な差は出ませんでした。

SafariやBabelで変換後のIEについては未調査ですので確実とは言えませんが、現行環境では意味のあるパフォーマンスの差は無いと推測されます。

Comments

[think49]

わざわざ検証コードを用意して頂き、ありがとうございます。
私の環境(Chrome 72.0.3626 / Windows 10 0.0.0)でも優位な差はありませんでした。
優劣は軽微で、優劣が逆転したり、ほぼ同等だったり安定しません。

arguments破壊については、どう思われますか。

[raccy]

「そもそもargumentsは使わない」の一言に尽きますね。Babelの変換でargumentsが現れて、それでおかしくなったら、そればBabel側のバグでしょというスタンスです。

私もあちらの質問でAirbnbの話を見て、「？」と思ってしまいました。オーバーロードの代わりに型変換して再代入はPythonやRubyではごく普通に使われているテクニックだったので。

[think49]

なるほど。@raccy さんらしい答えですね。
引数名とargumentsは衝突しますが、Rest Parametersは引数そのものなので、衝突対象がないのが良いです。
function foo (a, ...args) {}
私がargumentsを使う時にも、Rest Parameters を arguments で代用するスタイルで書いています。
また、アロー関数を使う時にはargumentsが使えないので、Rest Parameters しか選択肢がないですね。

> オーバーロードの代わりに型変換して再代入はPythonやRubyではごく普通に使われているテクニックだったので。
jQuery() のように引数の意味が変わるなら、別の変数名で再定義しますが、意味が変わらないなら、私も再代入を積極的に使っています。