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

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

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

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

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

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

Какое отношение к обсуждаемому имеют софтверные компании?! Код не перестанет работать, не нужно коспироложества здесь.

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

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

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

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

 
fxsaber:

Ну а пример выше с Lots[] - это настоящий клад, показывающий, как код может быть одновременно супер-лаконичным и абсолютно понятным.

Это для Вас код понятный. А тот, кто только посмотрел документацию и увидел ваш код сразу станет задаваться вопросом: почему же массив имеет размер 8, а типов ордеров в документации только 6.

И лично мне тоже удобнее читать условия, если они разделены по отдельности, т.е. вот так:

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

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

if (OrderMagicNumber() != m_nMagicNumber)
   continue;

мне тоже удобнее, чем так:

if (OrderSelect(i, SELECT_BY_POS) && OrderSymbol() == Symbol() && OrderMagicNumber() == m_nMagicNumber)
{
}

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

С другой стороны, я согласен с вами, что:

MT4-история торгов отсортирована по времени закрытия и это правило меняться не будет.

И считаю это логичным, и других времен не помню.

 
Alexey Kozitsyn:

Это для Вас код понятный. А тот, кто только посмотрел документацию и увидел ваш код сразу станет задаваться вопросом: почему же массив имеет размер 8, а типов ордеров в документации только 6.

Вот видите, как простой код рождает в головах правильные вопросы! И стоит ли после этого доверять всему, что написано в Документации?

 
fxsaber:

И стоит ли после этого доверять всему, что написано в Документации?

стоит, это основной принцип программирования RTFM 

RTFM
  • lurkmore.to
RTFM (изначально сокр. от англ. read the following manual, «обратитесь к прилагаемому руководству») — типичный ответ службы поддержки на вопрос пользователя, обычно сопровождающийся номером или названием этого руководства.
 
Igor Makanu:

стоит, это основной принцип программирования RTFM 

Реалии противоречат этому принципу.

 
fxsaber:

Какое отношение к обсуждаемому имеют софтверные компании?!

Ну а кого еще привести в качестве авторитета?

Код не перестанет работать, не нужно коспироложества здесь.

Да, в МТ4 с вероятностью 99% это так, потому что МТ4 уже почти похоронен. А вот попробуйте провернуть такой финт кроссплатформенно и сразу наткнетесь на исчезающий дефект, приводящий к fatal error.

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

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

Зачем слушать из космоса проклятия в свой адрес от того, кто работает с Вашим кодом? ))

 
Ihor Herasko:

Ну а кого еще привести в качестве авторитета?

Странно, что здесь затрагивается понятие авторитета.

Да, в МТ4 с вероятностью 99% это так, потому что МТ4 уже почти похоронен. А вот попробуйте провернуть такой финт кроссплатформенно и сразу наткнетесь на исчезающий дефект, приводящий к fatal error.

В MT5 пишу идентично...

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

А ведь есть еще конструкции if -> else if -> else if -> else. Не понимаю, почему bool-выражение в условном операторе нужно приводить в самом примитивном виде.

 
Alexey Kozitsyn:

Это для Вас код понятный. А тот, кто только посмотрел документацию и увидел ваш код сразу станет задаваться вопросом: почему же массив имеет размер 8, а типов ордеров в документации только 6.

И лично мне тоже удобнее читать условия, если они разделены по отдельности, т.е. вот так:

мне тоже удобнее, чем так:

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

С другой стороны, я согласен с вами, что:

И считаю это логичным, и других времен не помню.

Вот это ключевые слова.

Лично меня вообще раздражает написание continue

Какой в них смысл???? Если читать 

if (OrderSelect(i, SELECT_BY_POS) && OrderSymbol() == Symbol() && OrderMagicNumber() == m_nMagicNumber)

всё читается по русски:

Если ордер выбран и символ ордера "наш" и магик тоже наш... то выполняем всё что заключено в фигурные скобки.

Но как не по-русски звучит:

Если ордер не выбран, идём нахрен...

Если символ ордера не наш, идём нахрен

и так далее.

Сколько-же раз надо себя послать туда...................

Видимо в mql3 в этом был смысл. Так сокращали время проверки условия. Тогда все условия проверялись от начала до конца. НО ведь уже давно ситуация исправлена и если проверка натыкается на невыполнение условия, то дальнейшая проверка прекращается. И все эти ухищрения не имеют абсолютно никакого смысла.

 
Alexey Viktorov:

Вот это ключевые слова.

Лично меня вообще раздражает написание continue

Какой в них смысл???? Если читать

всё читается по русски:

Если ордер выбран и символ ордера "наш" и магик тоже наш... то выполняем всё что заключено в фигурные скобки.

Но как не по-русски звучит:

Если ордер не выбран, идём нахрен...

Если символ ордера не наш, идём нахрен

и так далее.

Сколько-же раз надо себя послать туда...................

Видимо в mql3 в этом был смысл. Так сокращали время проверки условия. Тогда все условия проверялись от начала до конца. НО ведь уже давно ситуация исправлена и если проверка натыкается на невыполнение условия, то дальнейшая проверка прекращается. И все эти ухищрения не имеют абсолютно никакого смысла.

Вы ведь сами согласились что это дело привычки. Меня, к примеру, раздражает лишняя вложенность, всегда ее убираю с помощью return, continue. А вместо "идем нахрен" легко привыкнуть читать "условия 1 и 2 выполнены":

if(!condition1 || !condition2)
   continue;
 
Vladislav Boyko:

Меня, к примеру, раздражает лишняя вложенность, всегда ее убираю с помощью return, continue

меня, к примеру, раздражает "Логическое отрицание НЕ(!)", мало того, что такт процессора забирает, так и чтение логического выражения превращается в чтение "шиворот-навыворот" ))) 

я всегда возвращаю в функциях bool "истину" как наиболее ожидаемый ответ, как пример: проверка доступности сервера у меня так:

bool ServerDisable(int count=10){
   for(int i=0;i<count;i++){
      if(IsConnected())
         if(IsTradeAllowed())
            if(!IsTradeContextBusy()){RefreshRates(); return(false);}
      Sleep(157);
   }
   Print(__FUNCTION__," Торговый сервер не отвечает");
return(true);}

вызываю вполне читаемо и логично:

if(ServerDisable()) return;

если сервер занят - выход, обычно в торговых функциях применяю, нечего сервер долбить запросами ибо он занят

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

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