条件文で（位置<サイズ）がこのような一般的なパターンになるのはなぜですか？

条件ステートメント（IF）では誰もがを使用(position < size)していますが、なぜですか？
慣習だけですか、それとも正当な理由がありますか？

野生で発見：

if (pos < array.length) {
   // do some with array[pos];
}

めったに見つかりません：

if (array.length > pos) {
   // do some with array[pos];
}

より深いパターンは、標準の順序として「[変化するもの] [比較] [変化しないもの]」を自然に使用するというものです。位置は変わるかもしれませんが、サイズは変わらないので、この原則はあなたの例に当てはまります。

唯一の一般的な例外は、バグではなく一般的なものを回避するために、一部のプログラマーが反対の順序（ヨーダ条件と呼ばれる）を使用するようにトレーニングするときです。これは、主に私たちがアイデアを英語で表現する方法であり、ほとんどの最新のコンパイラがこれを検出して警告を発行するためです。variable = constantvariable == constant

私がこれまでに見た唯一の正当化は、それが私たちが学校で学んだ数直線または他の順序付けのようなものであるということです。たとえば、次のように数行を記述します。

<--|--|--|--|--|--|-->
   1  2  3  4  5  6

小さいものは大きいものの左側に表示されます。同じことが日付などの他の事柄にも当てはまります（カレンダーのレイアウトを考えてみてください）。

基本的には、物事の順序について自然に考える方法に要約されます。最初のフォームは、メンタル処理をあまり行う必要がないため、読みやすくなっています。

それは主に慣習の問題ですが、これは私たちの考え方に最もよく一致すると私は考えています。強調する項目を示しています。

これらを英語に翻訳すると、「位置が配列の長さよりも小さい場合」というフレーズになります。この場合、文の主語は一時的な項目です。

逆に言うと、「配列の長さが位置よりも大きい場合」は、配列の長さ（固定値と見なされます）を主語に入れ、位置（一時的）が直接オブジェクトになります。

私の意見、そしてこれは私の意見にすぎませんが、それは読みやすさのための慣習だということです。2つは同じですが、私の脳内で異なる感じ。配列のサイズがposよりも大きいかどうか知りたくありません。posが配列サイズより小さいかどうか知りたい。

それは半分空の対半分の議論のようなものです。数学的には同じですが、私の脳は状況に応じて異なって見えます。

個人的には

if (array.lengh > pos) {
    // do some with array[pos];
}

それがバグかどうか、そしてプログラマーが何を意味しているかについて考え始めます。彼は境界チェック以外のことをしようとしていますか？

たぶん私は明るくないかもしれませんが、コードのすべての行でそのような分析をしなければならない場合、私の脳は痛いです。

別の方法で、誰かが試みたものを表現するために...

順序がプログラムの動作に影響を与えない場合、違いは明らかに人間が最も読みやすいものの問題です。「トピック」を左側に置くことが理にかなっている言語上の理由は次のとおりです。

言語学では、文のトピックは話されているものであり、コメントはトピックについて話されているものです。この例では、我々はそれが取り得るpositionあるトピック「配列の長さ未満」である、とコメント。英語および他の多くの言語では、トピックは通常コメントの前に表現されます。
「トピック化された構成要素を文の最初に配置する傾向（トピックの先頭）が広まっています。」

親指の良いルールは、（この場合、または句）文などのコードのあなたのラインを考える文が何であるかを決定することですので程度、およびできれば最初にそれを置きます。多くの場合、「約」という文は、定数ではなく変数になります。しかし、コメントには変数も含まれることがあるので、それだけではいきません。

これは2つの要素の組み合わせであり、どちらも初期の言語がコンパイルされた元になるアセンブラ（および現在の多くのアセンブラ）に由来しています。

1. 配列はメモリ内のゼロベースのオフセットです（つまり、データの最初のチャンクは割り当てられたメモリブロックの先頭にあります... 0インデックス）。したがって、変化するピースに0..n-1を使用します。

2. 値が別の値（またはレジスターなど）より小さい場合の分岐は、通常、単一の命令です。したがって、単純な小なり（<）演算子を使用します。

したがって、パターンは旧式のアセンブラーからANSI-C（いくつかの点でマクロアセンブラーに似ている）に移行し、そこからJavaや他のCのような言語に移行しました。

他の多くの答えが言ったように、それは非常にしばしば読みやすいです：

[thing that varies] [comparison] [thing that does not vary]

私が知っているほとんどすべての人がこのスタイルを独占的に使用しています。

=割り当てと==比較に使用するCスタイルの言語には、1つの例外があります。誤って入力した場合：

if (variable = 5) ...

の代わりに：

if (variable == 5) ...

これは有効なコード行であるため、エラーは発生しません。（一部のコンパイラーおよびIDEはこれを行うことについて警告しますが、そのような単純なタイプミスがあることは依然として非常に簡単です。）

ただし、次のように記述した場合：

if (5 == variable) ...

コンパイラー/インタープリターは、有効な構成ではないため、エラーになります（とにかくほとんどの言語で）。

この切り替えは、よくヨーダ条件と呼ばれます。

更新：ヨーダコンディションが役立つ場所のリストです。

個人的に、私はこれを好みます：

bool positionIsWithinBounds = pos < array.length;
if (positionIsWithinBounds) {
   // do some with array[pos];
}

...それはより多くのコードですが、非常に読みやすいです。

それは好みや慣習の問題です。一貫性を保ちたい場合は、次の2つの同等の合理的な方法で対処できます。

1. 常に「主語」を最初に置いてください（それを文と考えてください）-テストが意味する値。だから例えばあなたは書くでしょうif (age>5)

2. または、常に小さい方の要素を最初に配置します（値は画面上で自然な順序で並べられているので、それを考えてください）。したがって、たとえばif (a<b)、このコードの大部分がaであるか、大部分がbであるかに関係なく、記述します。

どちらの規則も、2番目ではなく最初に示したスニペットを推奨するので、この特定のケースでは答えがあると思います。ここで（1）と（2）の両方に違反するコードを記述しないようにするのが賢明だと思います。これは、ほとんどの人にとって読みにくくなるためです。