А можно мне поворчать? Ну, если ты правда учишься для себя, а не формально спустя рукава для галочки?)
У кода есть культура, и к ней лучше сразу жёстко приучиться, потому что она и себе же помогает, и другим, и исключает ошибки в коде.
В школах нас ужасно и учили - всякие i, j, k в циклах, которые ни фига не значат и по ним ни фига не поймёшь все эти a[i][k] := b[i][j];
Я давно учился прогать на других языках, и оттуда стащил принципы именования переменных, такие: переменная называется по схеме "префикс типа" + "группа" + название.
То есть нужно делать так, чтобы название переменной было читаемым, и чтобы при была понятно то, куда эта переменная относится.
Например переменные для режимов "Нагрев включен" и "Ошибка нагревателя" можно обозвать так
* bNagrevON
* bNagrevERR
b - это BOOL. А дальше обрати внимание, что по русски мы назвали "Ошибка нагревателя", а название переменной перевернули наоброт, написав не "bERRNagrevatel", а "bNagrevERR", чтобы при выводе всяких подсказок (вызываются по F2 в CodeSys v2 и по точке в CodeSys v3) переменные для нагревателя оказались рядом по списку.
Поэтому в моём примере я например минимумы и максимумы массивов зафигачил с префиксом этих массивов. То есть не Min_Array1, а Array1_Min.

Ещё важно писать код так, чтобы в будущем он был универсальный. Это про "магические числа".
Короче, всякие времена задержек, границы массивов удобно выносить в переменные или константы, чтобы их можно было легко подстроить или понимать, что это такое.
Ну, образно, если у нас на каком-то таймере будет задано время в t#300ms, то мы хрен что поймём потом. А если это время будет внесено в константу и будет названо как tHeatDelay (НагревЗадержка), то и код будет понятным, и в будущем это время можно будетлегко в одном месте кода подкорректировать