Почему (позиция <размер) такой распространенный паттерн в условных выражениях?

В выражении условия (IF) все используют (position < size), но почему?
Только конвенция или есть веская причина для этого?

Найдено в дикой природе:

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

Редко встречается:

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

Более глубокий паттерн состоит в том, что мы естественным образом используем «[вещь, которая варьируется] [сравнение] [вещь, которая не меняется]» в качестве стандартного порядка. Этот принцип справедлив для вашего примера, потому что позиция может меняться, а размер - нет.

Единственным распространенным исключением является то, что при тестировании на равенство некоторые программисты учатся использовать противоположный порядок (известный как условия Йоды ), чтобы избежать общего, variable = constantа не variable == constantошибочного - я не придерживаюсь этой идеи, потому что нахожу описанный естественный порядок выше, гораздо более читабельно, в первую очередь потому, что именно так мы выражаем идею на английском языке, и потому что большинство современных компиляторов обнаружат это и выдадут предупреждение.

Единственное оправдание, которое я когда-либо видел, это то, что это похоже на числовые строки или другие упорядоченные вещи, которые мы изучали в школе. Например, мы пишем числовые строки следующим образом:

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

Меньшие вещи появляются слева от больших вещей. То же самое относится и к другим вещам, таким как даты (подумайте, как устроен календарь).

Это в основном сводится к тому, как мы естественным образом думаем о порядке вещей. Первую форму легче прочитать, потому что вам не нужно много думать о ней.

Хотя это в основном вопрос соглашения, по моему мнению, это лучше всего соответствует тому, как мы думаем, - оно показывает пункт, на котором мы делаем упор.

Если мы переведем их на английский, это будет фраза «Если позиция меньше длины массива», где предметом предложения является временный элемент.

Чтобы выразить это иначе, «если длина массива больше, чем позиция» помещает длину массива (предполагается, что это фиксированное значение) в субъекте, и позиция (переходный процесс) становится прямым объектом.

Мое мнение, и это только мое мнение, состоит в том, что это соглашение для удобочитаемости. Хотя эти два идентичны, они чувствуют себя по-разному в моем мозгу. Я не хочу знать, если размер массива больше, чем pos. Я хочу знать, если pos меньше, чем размер массива.

Это как полупустое или наполовину полное обсуждение. Математически идентично, но мой мозг увидит их по-разному в зависимости от контекста.

Лично если я увижу

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

Я начну думать о том, является ли это ошибкой и что имел в виду программист. Он пытается сделать что-то кроме проверки границ?

Может быть, я просто не умный, но если мне придется проводить такой анализ каждой строки кода, мой мозг болит.

Чтобы выразить то, что некоторые пытались достичь, по-другому ...

Когда порядок не имеет значения для поведения программы, разница явно зависит от того, что является наиболее читаемым для людей. Вот лингвистическая причина, по которой смысл «темы» слева имеет смысл:

В лингвистике тема предложения - это то, о чем говорят, а комментарий - это то, что говорится о теме. В этом примере мы можем предположить, что positionэто тема , а «меньше длины массива» - это комментарий . На английском и многих других языках тема обычно выражается перед комментарием.
« Тенденция ставить тематические составные предложения изначально (тема выходит на передний план) широко распространена ».

Поэтому хорошее практическое правило - думать о вашей строке кода как о предложении (или в данном случае о предложении), решать, о чем идет речь , и ставить его первым, если можете. Часто то, о чем идет речь в «предложении», будет переменной, а не константой. Но иногда в комментарии также включается переменная, поэтому вы не можете просто пойти этим путем.

Это комбинация двух вещей, оба исходящие от базового ассемблера, к которому были скомпилированы ранние языки (и многие современные).

1. Массивы - это смещения, начинающиеся с нуля в памяти (т. Е. Первый фрагмент данных находится в начале выделенного блока памяти ... 0-индекс). Следовательно использование 0..n-1 для изменяющейся части.

2. Ветвление, если значение меньше, чем другое значение (или регистр и т. Д.), Обычно представляет собой одну инструкцию. Отсюда и использование простого оператора меньше чем (<).

Таким образом, шаблон переместился из устаревшего ассемблера в ANSI-C (который в некотором роде больше похож на макро-ассемблер) и оттуда в Java и другие C-подобные языки.

Как говорили многие другие ответы, очень часто легче читать:

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

Почти все, кого я знаю, используют этот стиль исключительно.

Есть одно исключение для языков C-стиля, которые используют =для присваивания и ==для сравнения. Если вы случайно набрали:

if (variable = 5) ...

вместо:

if (variable == 5) ...

тогда вы не получите ошибку, потому что это верная строка кода. (Некоторые компиляторы и IDE будут предупреждать вас об этом, но все еще очень легко иметь такую ​​простую опечатку.)

Однако, если вы напишите:

if (5 == variable) ...

Компилятор / интерпретатор выдаст ошибку, потому что это недопустимая конструкция (во всяком случае, в большинстве языков).

Такое переключение часто называют условием Йоды .

ОБНОВЛЕНИЕ : Вот список мест, где условия Yoda полезны .

Лично я предпочитаю это:

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

... это больше кода, но также очень легко читается.

Это вопрос предпочтений или условностей. Если вы хотите быть последовательным, есть два одинаково разумных способа сделать это:

1. Всегда ставьте «субъект» первым (думайте об этом как о предложении) - значение, о котором идет тест. Так, например, вы написали быif (age>5)

2. Или всегда ставьте меньший элемент первым (думайте, что значения расположены на экране в естественном порядке). Так, например, вы написали бы if (a<b)независимо от того, относится ли этот код в основном к a или к b.

Оба соглашения рекомендуют первый фрагмент, который вы показали, вместо второго, так что я думаю, что в данном конкретном случае у вас есть ответ. Я бы сказал, что было бы разумно избегать написания кода, который нарушает и (1), и (2), так как это затруднит чтение для большинства людей.