Adviser's project - page 2

New comment
 
Vasiliy Sokolov:

Rearranging the brackets doesn't make it any less of a mess. Before you give advice, at least bring your level up to average.

What's wrong with my level?

 
STARIJ:

The commentary should occupy half of the programme text

I even write some things - first a long commentary "what should happen here", and then code that implements it :-) By the way, I advise this approach for newbies too
 
Maxim Kuznetsov:
Some things I write - first a long comment "what should be there", and then code that implements it :-) By the way, I advise such an approach for newbies, too
First a stub for function with description what it will do and return(something). Then the code
 
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 is not difficult, and now you will always know what the code is, and reduce the time to study it


Vitaly, I got it right, you have a 12" laptop screen?

I remember in the old days, at CV-1420 with alphanumeric screen 24 lines x 80 characters, too, tried to save space )) Now somehow I try to write it so that it's quicker to understand.

 
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

And then pick up with your eyes what these 4 brackets at the bottom refer to. This is a very bad codestyle. In general MS has the best, and the fact that MQ professes to be K&R style is no reason to emulate it. The times of punched cards and 80x24 monitors are long gone.

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:
Well, then 90% of the code are comments. Besides, there has to be as much meaningless and bad-readable code as possible, so that it would be possible to put more comments!

But when I'm old I can publish the comments in the form of a book "Forex and Me" )))). No, I'd rather it be "Me and Forex".

 
Alexey Volchanskiy:

And then pick your eyes as to what those four brackets at the bottom refer to. This is a very bad codestyle. In general MS has the best, and the fact that MQ professes K&R style is no reason to emulate it. The times of punched cards and 80x24 monitors are long gone.


But when I'm old I can publish the comments in the form of a book "Forex and Me" )))). No, I prefer "Me and Forex".

Work screen 27".

I'm not going to re-read it, but to quote:"Don't write functions that are always constant and never change in this style"

Why pick your eyes over a function that is written once when the platform is released and will never change in the future? Do you often change/edit code in functions to get lot size, number of orders and typical? Then why stretch it across 3 screens of a 32" monitor?

P.S. The code attached is forged from kodobase.

 
Vitaly Muzichenko:

27" working screen

I'm not going to reread it, I'll just quote:"Don't write functions that are always constant and never change in that style"

Why pick your eyes over a function that is written once when the platform is released and will never change in the future? Do you often change/edit code in functions to get lot size, number of orders and typical? Then why stretch it across 3 screens of a 32" monitor?

The file where they lie is opened once every three hundred years in the same way.

And when it does open - go find it in a pile }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} what is what.

Why would you write a trap for yourself if you wrote it, tested it and sent it to a library or a class for storage? That's it. And when you need to refresh your memory (may be, you need to do something on the basis of it, whatever... you need to add something ) - you just sit and move parentheses...

 
Vitaly Muzichenko:

27" working screen

I'm not going to reread it, I'll just quote:"Don't write functions that are always constant and never change in that style"

Why pick your eyes over a function that is written once when the platform is released and will never change in the future? Do you often change/edit code in functions to get lot size, number of orders and typical? Then why stretch it across 3 screens of a 32" monitor?

P.S. The code is attached pulled from kodobase.

Vitaly, the first version of your function clearly shows which closing bracket refers to which opening one, while the second version breaks your eyes looking for a pair...

Usually custom functions are not so large that they cannot fit on the screen. And it doesn't matter at all how the brackets are arranged in the compiled EA.

 
Artyom Trishkin:

The file where they lie is also opened once every three hundred years.

But when it does open, you'll have to search through the }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} pile to find out what's what.

Why write a trap for yourself, if you write it, test it and send it to the library or class for storage. That's it. And when you need to refresh your memory (maybe base something on it, you never know...) - just sit and move parentheses...

No, I don't have anything in the file, I'm not greedy and I share programs with acquaintances and very often, and instead of sending archives, I send just one file.

All functions are at the bottom, but the executive code is always well written and commented, even a child can figure it out.

 
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?

I have several thousand lines of code in any EA. (They are automatically included through inclusions.)

In fact, an EA consists of the CExpert class-template, which has functions OnInit, OnTick, etc. In the connecting template of the EA, all global functions - events - call the corresponding functions of this type of object.

During initialization - CExpert requests via predefined global function "EA parts factory", which knows how to create all necessary for work.

The Expert Advisor itself consists of five lines. The object of the EA's parts factory itself is declared in this file, and the inclusions are included.

I personally really like the OOP approach, with the division of virtual interfaces and implementation. First, we describe the interface file - an abstract class in which all functions are virtual and equal to zero. This class defines the "interaction protocol". And then, we inherit real classes from it in which all of these functions are fully implemented (sometimes we have a whole hierarchy of classes, when the description of functions is distributed "by level").

This approach - allows to separate entities, which makes it very easy to further support the whole project, as well as reuse classes.

1234567
New comment