Особенности языка mql4, тонкости и приёмы работы - страница 12

Новый комментарий
 
Ihor Herasko:

Во многих софтверных компаниях за такой код бы все пальцы отбили. Первое, что требуется всегда и везде - это отсутствие "лишнего чтения". Например, если при входе в функцию используется условие:

то рекомендуется написать:

Такой подход очень выручает от вложения условий.

Еще раз - пальцы поотбивать. Ведь то, что вернула функция OrderType() никто не проверил. А может она вернула -1 или 6? Это пример закладывания на свойства компилятора, от чего всегда нужно держаться подальше. Вы же сами приводите много примеров кроссплатформенного кода. Так почему же в данном случае уходите от него? Выйдет новый компилятор от MQ и этот код перестанет корректно работать.

С continue та же самая ситуация. Код типа:

читается тяжелее, чем:

А ведь эффективность исполнения в обоих случаях одинакова.

Это-же полная жесть:

if (!OrderSelect(i, SELECT_BY_POS))
   continue;

if (OrderSymbol() != Symbol())
   continue;

if (OrderMagicNumber() != m_nMagicNumber)
   continue;
 
Vitaly Muzichenko:

Это-же полная жесть:

В чем жесть? Одна строка супервыражения - вот, где жесть. Человек - не компьютер, чтобы сходу понять, что дальше условие обрабатывать не нужно. Человеку, в отличии от компьютера, приходится вычислять все выражение до конца, а потом только понимать, что уже первая его составная часть приводит к ложному результату.

В записи же, где все разложено по простым условиям, такой расчет не нужен: первое условие не выполнено - ушли. 

Экономить нужно время, а не строки. Здесь же ратуют за лаконичность кода, которая на самом деле является упаковкой операций и условий друг в друга. Ладно бы эта упаковка давала ощутимый прирост производительности, я бы еще понял. Но ведь - нет. Максимум роста - в пределах погрешности измерений. Люди занимаются экономией строк, но вовсе не думают об экономии времени, затраченного на понимание и отладку кода.

 
Ihor Herasko:

В чем жесть? Одна строка супервыражения - вот, где жесть. Человек - не компьютер, чтобы сходу понять, что дальше условие обрабатывать не нужно. Человеку, в отличии от компьютера, приходится вычислять все выражение до конца, а потом только понимать, что уже первая его составная часть приводит к ложному результату.

В записи же, где все разложено по простым условиям, такой расчет не нужен: первое условие не выполнено - ушли. 

Экономить нужно время, а не строки. Здесь же ратуют за лаконичность кода, которая на самом деле является упаковкой операций и условий друг в друга. Ладно бы эта упаковка давала ощутимый прирост производительности, я бы еще понял. Но ведь - нет. Максимум роста - в пределах погрешности измерений. Люди занимаются экономией строк, но вовсе не думают об экономии времени, затраченного на понимание и отладку кода.

Я бы не назвал это сложночитаемым супервыражением.

if(!OrderSelect(i, SELECT_BY_POS) || OrderSymbol() != Symbol() || OrderMagicNumber() != m_nMagicNumber)
   continue;

Да и "короткий цикл вычисления" - базовая вешь, которая "автоматически" учитывается при чтении условия, не требуя никаких умственных усилий на это.

Опять-же, чисто субъективное мнение.

 
Vladislav Boyko:

Вы ведь сами согласились что это дело привычки.

И ещё раз повторю. Я никого не призываю менять свои привычки и искать разницу во вкусах фломастеров.

Igor Makanu:

как уже сказали - дело вкуса, но как известно: на вкус все фломастеры разные )))

Фломастеры разные только на цвет, а на вкус они одинаковые.
 
Vladislav Boyko:

Я бы не назвал это сложночитаемым супервыражением.

А здесь и не нужно ничего называть. Пока мои оппоненты (Вы в том числе) не привели ни одного аргумента в пользу того, что это выражение читается проще, чем разбивка по строкам.

От меня же было приведено целых три аргумента:

  1. Длинная строка не помещается в поле зрения. Требуется хотя бы минимальный поворот головы (увеличивается время обработки). Короткая строка и следующая за ней не требуют таких затрат.
  2. В длинной строке проще допустить ошибку и не заметить ее. При разбивке на строки вероятность такого рода ошибки уменьшается.
  3. Длинную строку невозможно отладить. Разбивка на строки - пожалуйста.
Никаких субъективных предпочтений. Все подтверждено практическим смыслом и не более. Да, кому-то удобнее чесать левое ухо правой пяткой, но это вовсе не значит, что такой подход практичен. А в природе все подчиняется именно практичности и выживают те, кто практичнее. 
 
Ihor Herasko:

А здесь и не нужно ничего называть. Пока мои оппоненты (Вы в том числе) не привели ни одного аргумента в пользу того, что это выражение читается проще, чем разбивка по строкам.

От меня же было приведено целых три аргумента:

  1. Длинная строка не помещается в поле зрения. Требуется хотя бы минимальный поворот головы (увеличивается время обработки). Короткая строка и следующая за ней не требуют таких затрат.
  2. В длинной строке проще допустить ошибку и не заметить ее. При разбивке на строки вероятность такого рода ошибки уменьшается.
  3. Длинную строку невозможно отладить. Разбивка на строки - пожалуйста.
Никаких субъективных предпочтений. Все подтверждено практическим смыслом и не более. Да, кому-то удобнее чесать левое ухо правой пяткой, но это вовсе не значит, что такой подход практичен. А в природе все подчиняется именно практичности и выживают те, кто практичнее. 

Игорь, если глаза не двигаются в глазницах и приходится поворачивать голову, то можно написать и так:

if(OrderSelect(i, SELECT_BY_POS)
&& OrderSymbol() == _Symbol
&& OrderMagicNumber() == m_nMagicNumber)
 {
  // Делаем что надо...
 }

А сколько я встречал коротких строк с ошибками........... Видимо от длины строки количество и вероятность ошибок не зависит.

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

 
Alexey Viktorov:

Игорь, если глаза не двигаются в глазницах и приходится поворачивать голову, то можно написать и так:

А сколько я встречал коротких строк с ошибками........... Видимо от длины строки количество и вероятность ошибок не зависит.

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

Можно и так, но с таким стилем чтобы просмотреть один блок программы - нужно сделать 2 прокрутки экрана, а это хуже, чем видеть весь код в одном экране. (Вас не касается, это просто пример)

 
fxsaber:

К сожалению, этот миф не находит никаких подтверждений в истории форума. Более того, разработчики постоянно четко обозначают свою позицию, что подобных изменений принципиально быть не может.

Было такое. Влияла сортировка.

Обсуждение, наверное, велось на старом форуме metatrader4.com (еще недавно открывался, сейчас редиректит на mql5.com).

 
Andrey Khatimlianskii:

Было такое. Влияла сортировка.

Обсуждение, наверное, велось на старом форуме metatrader4.com (еще недавно открывался, сейчас редиректит на mql5.com).

Было, было. Так-же как и сейчас с количеством исторических ордеров, если поставить "Сегодня", то OrdersHistoryTotal() вернёт то количество закрытых, которые закрылись сегодня. Если в закладке "История" не отображается какой-то старый ордер, то он недоступен даже по тикету.

 
Alexey Viktorov:

Было, было. Так-же как и сейчас с количеством исторических ордеров, если поставить "Сегодня", то OrdersHistoryTotal() вернёт то количество закрытых, которые закрылись сегодня. Если в закладке "История" не отображается какой-то старый ордер, то он недоступен даже по тикету.

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

А разве сейчас глубина истории не зависит от выбранной на вкладке? По-моему как зависело, так и зависит.

1...5678910111213141516171819...36
Новый комментарий
Причина обращения: