Проект советника

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

А много это сколько?... Это столько что уже по файлам не разбить? 

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

Два основных принципа: 

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

2. Сокращать количество глобальных переменных. Из глобальных переменных желательно использовать только параметры не меняющиеся в процессе работы программы.  

...и еще:

3. Объектно ориентированное программирование.

4. Размещение кода в нескольких файлах (тут несколько усложняется отладка, но смысл в этом есть). 

 
STARIJ:
Да все очень просто: надо отдельные функции точно задокументировать и выделить в отдельный файл. Главный файл сразу же уменьшится и станет более читабельным

У меня всегда один файл mq4/mq5 и куча файлов mqh с классами, на каждый класс отдельный файл. В общем, при промышленной разработке именно так и поступают. Никаких километровых файлов, куда все напихано вперемежку.

А то еще иногда встречаешь шедевры, когда весь советник умещается в OnTick, при этом в этой безобразной простыне по 20 раз встречаются одинаковые куски кода по открытию ордеров. Хочется сразу достать блевотный пакетик ))

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

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

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());
                 }
              }
           }
        }
     }
  }

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

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());
    }
}}}}


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

 
Vitaly Muzichenko:

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

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

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

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

 
Vitaly Muzichenko:

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

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

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

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

 
STARIJ:

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

Не, ну тогда сразу 90% кода - комментарии. При том нужно как можно больше бессмысленного и плохочитаемого кода, что бы комментариев можно было побольше поставить!
 
Vasiliy Sokolov:
Не, ну тогда сразу 90% кода - комментарии. При том нужно как можно больше бессмысленного и плохочитаемого кода, что бы комментариев можно было побольше поставить!

идеи Ваши также заслуживают внимания. Почаще выносите их на обсуждение

 

Давно хотел спросить. Если в мкл5 получать данные  индикатора из включаемых файлов, классах, то быстрее будет оптимизация?

То есть в коде самого советника никакие хендлы индикаторов не вызываются.

Причина обращения: