Adviser's project

New comment
 
Hello.
As the amount of code grows, it sometimes gets difficult and confusing.
I have seen EA code with a huge number of lines of code, I wonder how complex EAs are designed, maybe there are some tools or techniques for dealing with such complex algorithms?
 
Gregory Kovalenko:
Hello.
As the amount of code grows, it sometimes gets difficult and confusing.
I've seen EA code with a huge number of lines of code, I wonder how complex EAs are designed, maybe there are some tools or techniques for working with such complex algorithms?

How much is too much? Is it so much that it can't be broken down into files?

 
Gregory Kovalenko:
Hello.
As the amount of code grows, it sometimes gets difficult and confusing.
I have seen EA code with a huge number of lines of code, I wonder how complex EAs are designed, maybe there are some tools or techniques for dealing with such complex algorithms?
Yes, it's very simple: you need to precisely document the individual functions and allocate them to a separate file. The main file will immediately shrink and become more readable
 

Two basic principles:

1. Divide the code into functions. One function should be more or less logically complete and be no more than one screen to be covered in one glance.

2. Reduce the number of global variables. From global variables, it is desirable to use only parameters which do not change while the program is running.

...and more:

3. object-oriented programming.

4. Placing the code into several files (this complicates debugging, but there is a sense in it).

 
STARIJ:
It's very simple: we need to precisely document the individual functions and allocate them into a separate file. The main file will immediately become smaller and more readable

I always have one mq4/mq5 file and a bunch of mqh files with classes, for each class a separate file. In general, this is how they do it in industrial development. No kilometer-long files where everything is mixed up.

Sometimes you can see a masterpiece where the entire EA is packed into OnTick with the same pieces of code for opening orders 20 times each in this ugly sheet. I want to take out the puke bag right away ))

 
Gregory Kovalenko:
Hello.
As the amount of code grows, it sometimes gets difficult and confusing.
I have seen EA code with a huge number of lines of code, I wonder how complex EAs are designed, maybe there are some tools or tricks for working with such complex algorithms?

Do not write functions that are always constant and never change in this style

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

Write them concisely, no one ever looks at them anyway, and they take up half as much space.

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


Comment on the code all the time, what this piece of code is responsible for, it is not difficult, and now you will always know what the code is, and reduce the time to study it

 
Vitaly Muzichenko:

Don't write functions that are always constant and never change in this style

Write them concisely, no one ever looks at them anyway, and they take up half as much space.

Comment on the code all the time, what this piece of code is responsible for, it's not difficult, and now you will always know what the code is, and reduce the time to study it

The comment must occupy half of the text of the program

 
Vitaly Muzichenko:

Don't write functions that are always constant and never change in this style

Write them concisely, no one ever looks at them anyway, and they take up half as much space.

Comment on the code all the time, what this piece of code is responsible for, it's not difficult, and here in the revision will always know what the code, and reduce the time to study it

Rearranging parentheses does not make the lag less. Before giving advice, at least raise your level to an average one.

 
STARIJ:

The commentary should occupy half of the programme text

Well, in that case 90% of the code should contain comments. And you need as much meaningless and poorly readable code as possible so that you could put more comments!
 
Vasiliy Sokolov:
No, well, then 90% of the code is comments. And you need as much pointless and poorly readable code as possible, so that you can put more comments!

Your ideas are also noteworthy. You should discuss them more often

 

I've been meaning to ask for a long time. If in mcl5 you get indicator data from include files, classes, will the optimization be faster?

That is, no indicator handles are called in the code of the Expert Advisor itself.

1234567
New comment
Reason: