Проект советника - страница 2

Новый комментарий
 
Vasiliy Sokolov:

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

А что с моим уровнем не так?

 
STARIJ:

Комментарий должен занимать половину текста программы

некоторые вещи вообще пишу - сначала пространные комментарии "что тут должно будет быть", а потом между ними код который это реализует :-) кстати и новичкам советую подобный подход
 
Maxim Kuznetsov:
некоторые вещи вообще пишу - сначала пространные комментарии "что тут должно будет быть", а потом между ними код который это реализует :-) кстати и новичкам советую подобный подход
Ну сначала заглушку для функции с описанием что будет делать и return(что нибудь). Потом код
 
Vitaly Muzichenko:

Не писать функции которые всегда постоянны и никогда не изменяются в таком стиле

Пишите их сжато, всё-равно в них никогда никто не смотрит, а строк занимает в два раза меньше


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


Виталий, я правильно понял, у Вас экран ноутбука 12"?

Помню, в древние времена на CV-1420 с алфавитно-цифровым экраном 24 строки х 80 знаков тоже старался место экономить )) Теперь как-то стараюсь писать так, чтобы быстрее понимать.

 
Vitaly Muzichenko:

Не писать функции которые всегда постоянны и никогда не изменяются в таком стиле

Пишите их сжато, всё-равно в них никогда никто не смотрит, а строк занимает в два раза меньше


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

И потом ковыряйся глазами, к чему относятся эти 4 скобки внизу. Это очень плохой codestyle. Вообще лучший у MS, а то, что MQ исповедуют стиль K&R, не является поводом для подражания. Времена перфокарт и мониторов 80х24 давно прошли.

void CloseOrders(int cmd) {
 for(int i=OrdersTotal()-1;i>=0;i--) {
  if(OrderSelect(i,SELECT_BY_POS)) {
   if(OrderSymbol()==Symbol() && OrderMagicNumber()==Magic) {
    if(OrderType()==OP_BUY && cmd==OP_BUY) {
     if(!OrderClose(OrderTicket(),OrderLots(),Bid,Slippage,Blue)) Print("Order BUY not close! Error = ",GetLastError());
    }
     if(OrderType()==OP_SELL && cmd==OP_SELL) {
      if(!OrderClose(OrderTicket(),OrderLots(),Ask,Slippage,Red)) Print("Order SELL not close! Error = ",GetLastError());
    }
}}}}
Vasiliy Sokolov:
Не, ну тогда сразу 90% кода - комментарии. При том нужно как можно больше бессмысленного и плохочитаемого кода, что бы комментариев можно было побольше поставить!

Зато под старость можно будет комментарии издать в виде книги "Форекс и Я" )))) Не, лучше так - "Я и форекс"

 
Alexey Volchanskiy:

И потом ковыряйся глазами, к чему относятся эти 4 скобки внизу. Это очень плохой codestyle. Вообще лучший у MS, а то, что MQ исповедуют стиль K&R, не является поводом для подражания. Времена перфокарт и мониторов 80х24 давно прошли.


Зато под старость можно будет комментарии издать в виде книги "Форекс и Я" )))) Не, лучше так - "Я и форекс"

Рабочий экран 27"

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

Зачем ковырять глазами функцию, которая пишется один раз при выходе платформы, и никогда не будет меняться в будущем? Вы часто меняете/редактируете код в функциях получения размера лота, количество ордеров и типичных? Тогда зачем её растягивать на 3 экрана 32" монитора?

P.S. Код приложен выковырянный с кодобазы.

 
Vitaly Muzichenko:

Рабочий экран 27"

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

Зачем ковырять глазами функцию, которая пишется один раз при выходе платформы, и никогда не будет меняться в будущем? Вы часто меняете/редактируете код в функциях получения размера лота, количество ордеров и типичных? Тогда зачем её растягивать на 3 экрана 32" монитора?

Так и файл, где они лежать, точно так же раз в триста лет открывается.

А вот когда открывается - поди найди в куче }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} что там к чему.

Зачем писать для себя же капкан, если написал, протестировал и отправил на хранение в библиотеку или класс. Всё. А вот когда понадобится освежить в памяти чего там (может на основе что-то сделать, да мало ли... else нужно добавить) - сиди, двигай скобки...

 
Vitaly Muzichenko:

Рабочий экран 27"

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

Зачем ковырять глазами функцию, которая пишется один раз при выходе платформы, и никогда не будет меняться в будущем? Вы часто меняете/редактируете код в функциях получения размера лота, количество ордеров и типичных? Тогда зачем её растягивать на 3 экрана 32" монитора?

P.S. Код приложен выковырянный с кодобазы.

Виталий, в первом варианте вышей функции чёткр прнятно какая закрывающая скобка к какой открывающей относится, а во втором варианте, глаза сломаешь в поисках пары...

Как правило пользовательские функции не такие уж большие чтобы не умещались на экране. А в откомпилированном советнике вообще глубоко плевать как там скобки расставлены.

 
Artyom Trishkin:

Так и файл, где они лежать, точно так же раз в триста лет открывается.

А вот когда открывается - поди найди в куче }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} что там к чему.

Зачем писать для себя же капкан, если написал, протестировал и отправил на хранение в библиотеку или класс. Всё. А вот когда понадобится освежить в памяти чего там (может на основе что-то сделать, да мало ли...) - сиди, двигай скобки...

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

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

 
Gregory Kovalenko:
Здравствуйте.
С увеличением объёма кода, возникает иногда затруднения и путаница. 
Я видел код советника с огромным количеством строк кода, интересно, как проектируют сложные советники, может есть какие-то инструменты или приёмы работы с такими сложными алгоритмами?

У меня в любом советнике несколько тысяч строк кода. (Они автоматически включаются через инклюды.)

Фактически, советник состоит из класса-шаблона CExpert, в котором есть функции OnInit, OnTick и прочие. В подключаемом шаблоне советника - все глобальные функции-события - обращаются к соотетствующим функциям объекта этого типа.

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

При этом сам файл советника состоит из пяти строк. В этом файле объявляется сам объект фабрики частей эксперта, и подключаются инклюды.

Лично мне очень нравится ООП-подход, с разделением на виртуальные интерфейсы и имплементацию. Сперва описываем файл интерфейса - абстрактный класс, в котором все функции виртуальны и приравнены к нулю. Этот класс задает "протокол взаимодействия". И потом, от него - наследуются реальные классы, в которых все эти функции полностью реализованы (иногда - получается целая иерархия классов, когда описание функций разнесено "по уровням").

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

1234567
Новый комментарий