forループ注釈でこの追加変数を使用する利点はありますか？

私が取り組んでいる大きなプロジェクト（擬似コード）で次のループアノテーションを見つけました。

var someOtherArray = [];
for (var i = 0, n = array.length; i < n; i++) {
    someOtherArray[i] = modifyObjetFromArray(array[i]);
}

私の注意を引いたのは、この余分な「n」変数です。このように書かれたfor lopを見たことはありません。

明らかにこのシナリオでは、このコードを次の方法で書くことができなかった理由はありません（私は非常に慣れています）：

var someOtherArray = [];
for (var i = 0; i < array.length; i++) {
    someOtherArray[i] = modifyObjetFromArray(array[i]);
}

しかし、それは私に考えさせられました。

そのようなforループを書くことが理にかなっているシナリオはありますか？「配列」の長さはforループの実行中に変わる可能性があるという考えが浮かびますが、元のサイズよりもさらにループしたくはありませんが、そのようなシナリオは想像できません。

OutOfBoundsExceptionが発生する可能性が高いため、ループ内で配列を縮小してもあまり意味がありません。

このアノテーションが役立つ既知のデザインパターンはありますか？

編集 @ Jerry101で述べたように、理由はパフォーマンスです。これが、私が作成したパフォーマンステストへのリンクです：http : //jsperf.com/ninforloop。私の意見では、非常に巨大な配列を繰り返し処理しているのでなければ、違いは十分に大きくありません。コピー元のコードは最大20個の要素しか持っていなかったため、この場合の読みやすさはパフォーマンスの考慮事項を上回ると思います。

この変数nは、生成されたコードがすべての反復で配列の長さをフェッチしないようにします。

これは、使用する言語、配列が実際にコレクションオブジェクトであるかJavaScript「配列」であるか、その他の最適化の詳細に応じて実行時間に違いをもたらす可能性がある最適化です。

配列の長さを取得することは、実際に反復するアクションよりも簡単に「より高価」になります。

したがって、セットが変更されない場合は、長さを一度だけ照会します。

配列ではなく、SQLサーバーからのレコードセットを使用して、繰り返しごとにレコードカウントをクエリしないことで劇的な改善が見られました。（もちろん、これを行うのは、このプロセス中に配列またはレコードセットが変更されないことを保証できる場合のみです）。

「配列」の長さはforループの実行中に変わる可能性があるという考えが浮かびますが、元のサイズよりもさらにループしたくはありませんが、そのようなシナリオは想像できません。

パフォーマンスについて話している人々はおそらくこれがそのように書かれている理由で正しいでしょう（そのように書いた人はパフォーマンスに大きな影響を与えることは正しくないかもしれませんが、それは別の問題です）。

ただし、あなたの質問のこの部分に答えるために、ループの主な目的がループしている配列を変更することである場合に起こる可能性が最も高いと思います。擬似コードで、次のようなものを検討してください。

guests = [];
for (i = 0; i < invitations.length; ++i) {
    if (! invitations[i].is_declined()) {
        guests.append(invitations[i].recipient())
    }
}
// maybe some other stuff to modify the guestlist
for (i = 0, n = guests.length; i < n; ++i) {
    if (guests[i].has_plus_one()) {
        guests.append(guests[i].get_plus_one());
    }
}

もちろん、それを書く他の方法があります。この場合、受信者が招待を受け入れたかどうかを確認すると同時に、プラスのものを確認し、一度に1つずつ招待状を作成します。これらの2つの操作を必ずしも組み合わせたいわけではありませんが、それが間違いであり、この設計が必要である理由をすぐに考えることはできません。場合によっては検討するオプションです。

実際、このコードで最も間違っているのは、guests配列のメンバーシップがコードの異なるポイントで異なることを意味することだと思います。したがって、私は確かにそれを「パターン」とは呼びませんが、この種のことをやめることを除外するのに十分な欠陥であることは知りません:-)

可能な限り、配列のすべての要素を走査する反復子を使用する必要があります。配列をランダムアクセスストレージとしてではなく、シーケンスとして使用するため、シーケンシャルアクセスを行うイテレータの方が高速であることは明らかです。配列は実際には二分木であると思いますが、誰かが要素を数えることで「長さ」を決定するコードと、i番目の要素にアクセスするコードを書きました。 ）。イテレータは非常に高速であり、ループはスローになります。