Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Во многих софтверных компаниях за такой код бы все пальцы отбили. Первое, что требуется всегда и везде - это отсутствие "лишнего чтения". Например, если при входе в функцию используется условие:
то рекомендуется написать:
Такой подход очень выручает от вложения условий.
Еще раз - пальцы поотбивать. Ведь то, что вернула функция OrderType() никто не проверил. А может она вернула -1 или 6? Это пример закладывания на свойства компилятора, от чего всегда нужно держаться подальше. Вы же сами приводите много примеров кроссплатформенного кода. Так почему же в данном случае уходите от него? Выйдет новый компилятор от MQ и этот код перестанет корректно работать.
Какое отношение к обсуждаемому имеют софтверные компании?! Код не перестанет работать, не нужно коспироложества здесь.
С continue та же самая ситуация. Код типа:
читается тяжелее, чем:
А ведь эффективность исполнения в обоих случаях одинакова.В данном случае код из одной строки читается легче, чем из шести. Более того, он логичнее, т.к. никак не завязан на необходимость быть внутри цикла. Т.е. первый вариант можно копи-пастить спокойно, второй - нет.
Ну а пример выше с Lots[] - это настоящий клад, показывающий, как код может быть одновременно супер-лаконичным и абсолютно понятным.
Это для Вас код понятный. А тот, кто только посмотрел документацию и увидел ваш код сразу станет задаваться вопросом: почему же массив имеет размер 8, а типов ордеров в документации только 6.
И лично мне тоже удобнее читать условия, если они разделены по отдельности, т.е. вот так:
мне тоже удобнее, чем так:
Но я считаю, что это дело вкуса и привычки. Никому не нужно ничего навязывать и доказывать.
С другой стороны, я согласен с вами, что:
И считаю это логичным, и других времен не помню.
Это для Вас код понятный. А тот, кто только посмотрел документацию и увидел ваш код сразу станет задаваться вопросом: почему же массив имеет размер 8, а типов ордеров в документации только 6.
Вот видите, как простой код рождает в головах правильные вопросы! И стоит ли после этого доверять всему, что написано в Документации?
И стоит ли после этого доверять всему, что написано в Документации?
стоит, это основной принцип программирования RTFM
стоит, это основной принцип программирования RTFM
Реалии противоречат этому принципу.
Какое отношение к обсуждаемому имеют софтверные компании?!
Ну а кого еще привести в качестве авторитета?
Код не перестанет работать, не нужно коспироложества здесь.
Да, в МТ4 с вероятностью 99% это так, потому что МТ4 уже почти похоронен. А вот попробуйте провернуть такой финт кроссплатформенно и сразу наткнетесь на исчезающий дефект, приводящий к fatal error.
В данном случае код из одной строки читается легче, чем из шести. Более того, он логичнее, т.к. никак не завязан на необходимость быть внутри цикла. Т.е. первый вариант можно копи-пастить спокойно, второй - нет.
Если говорить именно о частном случае, то может быть и так, потому что приведенный код является чуть ли не стандартным для каждого эксперта. Но если взять что-то посложнее, то его чтение при написании в одну строку сразу затрудняется.
Зачем слушать из космоса проклятия в свой адрес от того, кто работает с Вашим кодом? ))
Ну а кого еще привести в качестве авторитета?
Странно, что здесь затрагивается понятие авторитета.
Да, в МТ4 с вероятностью 99% это так, потому что МТ4 уже почти похоронен. А вот попробуйте провернуть такой финт кроссплатформенно и сразу наткнетесь на исчезающий дефект, приводящий к fatal error.
В MT5 пишу идентично...
Если говорить именно о частном случае, то может быть и так, потому что приведенный код является чуть ли не стандартным для каждого эксперта. Но если взять что-то посложнее, то его чтение при написании в одну строку сразу затрудняется.
А ведь есть еще конструкции if -> else if -> else if -> else. Не понимаю, почему bool-выражение в условном операторе нужно приводить в самом примитивном виде.
Это для Вас код понятный. А тот, кто только посмотрел документацию и увидел ваш код сразу станет задаваться вопросом: почему же массив имеет размер 8, а типов ордеров в документации только 6.
И лично мне тоже удобнее читать условия, если они разделены по отдельности, т.е. вот так:
мне тоже удобнее, чем так:
Но я считаю, что это дело вкуса и привычки. Никому не нужно ничего навязывать и доказывать.
С другой стороны, я согласен с вами, что:
И считаю это логичным, и других времен не помню.
Вот это ключевые слова.
Лично меня вообще раздражает написание continue
Какой в них смысл???? Если читать
всё читается по русски:
Если ордер выбран и символ ордера "наш" и магик тоже наш... то выполняем всё что заключено в фигурные скобки.
Но как не по-русски звучит:
Если ордер не выбран, идём нахрен...
Если символ ордера не наш, идём нахрен
и так далее.
Сколько-же раз надо себя послать туда...................
Видимо в mql3 в этом был смысл. Так сокращали время проверки условия. Тогда все условия проверялись от начала до конца. НО ведь уже давно ситуация исправлена и если проверка натыкается на невыполнение условия, то дальнейшая проверка прекращается. И все эти ухищрения не имеют абсолютно никакого смысла.
Вот это ключевые слова.
Лично меня вообще раздражает написание continue
Какой в них смысл???? Если читать
всё читается по русски:
Если ордер выбран и символ ордера "наш" и магик тоже наш... то выполняем всё что заключено в фигурные скобки.
Но как не по-русски звучит:
Если ордер не выбран, идём нахрен...
Если символ ордера не наш, идём нахрен
и так далее.
Сколько-же раз надо себя послать туда...................
Видимо в mql3 в этом был смысл. Так сокращали время проверки условия. Тогда все условия проверялись от начала до конца. НО ведь уже давно ситуация исправлена и если проверка натыкается на невыполнение условия, то дальнейшая проверка прекращается. И все эти ухищрения не имеют абсолютно никакого смысла.
Вы ведь сами согласились что это дело привычки. Меня, к примеру, раздражает лишняя вложенность, всегда ее убираю с помощью return, continue. А вместо "идем нахрен" легко привыкнуть читать "условия 1 и 2 выполнены":
if(!condition1 || !condition2) continue;
Меня, к примеру, раздражает лишняя вложенность, всегда ее убираю с помощью return, continue
меня, к примеру, раздражает "Логическое отрицание НЕ(!)", мало того, что такт процессора забирает, так и чтение логического выражения превращается в чтение "шиворот-навыворот" )))
я всегда возвращаю в функциях bool "истину" как наиболее ожидаемый ответ, как пример: проверка доступности сервера у меня так:
вызываю вполне читаемо и логично:
если сервер занят - выход, обычно в торговых функциях применяю, нечего сервер долбить запросами ибо он занят
как уже сказали - дело вкуса, но как известно: на вкус все фломастеры разные )))