Forex и другие финансовые инструменты на nikitos.org

Новости

12 апреля 2017 года

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

11 марта 2017 года

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

Читать далее>>

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

Однако среди программистов бытует мнение, что программ без ошибок не бывает, поэтому, как и любая другая программа, советник (или индикатор, или скрипт) на MQL также требует тестирования. Необходимость в этой процедуре приходит где-то после того момента, когда из-за ошибки в коде советник открывает крайне невыгодную сделку, которая стоит трейдеру значительную часть депозита. Кроме того, говоря о тестировании торговых стратегий, можно еще говорить о технологии подбора оптимальных параметров, дающих приемлемый показатель прибыли и позволяющих избежать частичной или полной потери депозита в результате движений рынка. Обе процедуры заслуживают внимания и освещения в данном разделе. Обратите внимание - все нижеизложенное является практическими наблюдениями и личным мнением автора, если у вас в результате использования рекомендаций из этого раздела что-то не получилось, это только ваша вина. Спасибо за понимание.

Итак - тестирование и отладка кода советника, его логики. Самый простой тест на грамотность написания программы - она компилируется. Проверьте, у вас так? Для этого в редакторе нажимаем "Компилировать" и смотрим, какие у нас ошибки или предупреждения. В принципе, если будут ошибки, то ничего не соберется, а предупреждения несут скорее информационный характер и в большинстве больших программ есть. В особенности это высказывание справедливо при установленном #property strict - в этом случае будет использоваться более строгая проверка исходного текста, и при создании шаблона советника этот режим включен по умолчанию. При удалении этой директивы многие ошибки "прощаются", например, неявное приведение типов. Может быть, это и не самая хорошая идея, но от лишних нервов сбережет. В конце концов, всегда можно включить "строгий" режим и проверить себя.

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

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

Если программа компилируется без ошибок, имеет смысл распечатать исходный код и еще раз внимательно его перечитать с карандашом в руках - добавляете новые комментарии, убираете лишнее, делаете код более читаемым. После проверки следует внести свои же правки в свой код. Если у вас есть знакомый MQL-программист, покажите код ему - возможно, где-то он его раскритикует (программисты обожают критиковать чужой код), но среди этой критики можно услышать и действительно здравые идеи - все же одна голова хорошо, а две - еще лучше. Однако излишне "светить кодом" не следует - это может привести к воровству действительно ценных идей и взаимным обидам, поэтому на этапе написания советника лучше исключить публикацию исходного кода.

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

Продолжение в разработке…