Alternative implementations of standard functions/approaches - page 8

[Реter Konow]

fxsaber:

An example of my style?

For example this:

return((int)((Value > 0) ? Value / Points[digits] + HALF_PLUS : Value / Points[digits] - HALF_PLUS) * Points[digits]);

Imagine you have 100 functions and each one returns such a record. You are looking for an error among these entries. How long will it take you to search?

[Vitaly Muzichenko]

Реter Konow:

For example this:

Imagine you have 100 functions and each one returns this record. You are looking for an error among these entries. How long will it take you to search?

I would not search for more than a couple of minutes, especially since a record in this style allows you to display more than a few dozen functions in "one screen", which makes it easier to work with the code

[fxsaber]

Реter Konow:

For example this:

Imagine you have 100 functions and each one returns this record. You are looking for an error among these entries. How long will it take you to find it?

Trust me when I write texts like that - it's not for the sake of style or brevity's principle but because it's really much easier for me.

You cited the simplest way. Honestly, I don't understand what could be the slightest bit confusing about it.

I must confess I can't read C++ code because I don't know it at all. But people write in it. So it's just a matter of ignorance.

[Реter Konow]

fxsaber:

Believe me, when I write it this way, it's not for the sake of style or brevity, but because it's really easier for me.

You've cited the simplest of terms. Honestly, I don't understand what could be the slightest bit confusing about it.

I must confess I can't read C++ code because I don't know it at all. But people write in it. So it's just a matter of ignorance.

Perhaps we have different ideas of code simplicity.

I understand that you are a great professional in programming. But when you pursue the highest productivity in everything you should not forget aboutlabor productivity. It begins with code readability. It's not clear to me why the urge to compress code at the expense of code readability is justified, but it is quite unacceptable in large (independent) projects.

Frankly speaking, I hate C++ because it's too unreadable. For piling up of entities whose existence could be easily avoided. And it's only going to get better. Spacious.

SZU. I believe that in development the code should be compressed not at the expense of readability but at the expense of better solutions, while leaving it as readable as possible. The speed of code comprehension has a huge impact on your own productivity.

ZSY. The thread is great. Thank you.

[Georgiy Merts]

Renat Fatkhullin:
Think about what you'll get outside an integer.

So the check for LONG_MAX - should be before converting double to long. Clearly, the rounding function is not designed for values that do not fit into an integer. And it does not change the problem.

If the function returns double that we then convert into long, we face the same danger of overflow.

Personally, just before rounding - I always have assert-check for boundary values, plus the logic of the program - I always look to ensure that the conversion can never get more than the maximum value for an integer.

[Georgiy Merts]

Vitaly Muzichenko:

I wouldn't look for more than a couple of minutes, especially since writing in this style allows you to display more than a few dozen functions in 'one screen', making it easier to work with the code

Something I doubt about that.

Here is the actual code of my function, that returns the type of execution (the code was suggested by fxsaber, for which I am very grateful to him):

// Для МТ4 - возвращает otfFilingType.
// Для МТ5 - возвращает тип исполнения ордера, равный otfFilingType, если он доступен на символе strSymbol, иначе - корректный вариант.

ENUM_ORDER_TYPE_FILLING CSymbolInfo::GetTypeFilling(string strSymbol,ENUM_ORDER_TYPE_FILLING otfFilingType = ORDER_FILLING_FOK)
{
   #ifndef __MQL5__
      return(otfFilingType);
   #else // __MQL5__
      
   // Функцию предложил fxsaber. Серьезной проверки не было - полагаемся на его авторитет.
      
   const ENUM_SYMBOL_TRADE_EXECUTION steExeMode = (ENUM_SYMBOL_TRADE_EXECUTION)::SymbolInfoInteger(strSymbol, SYMBOL_TRADE_EXEMODE);
   const int iFillingMode = (int)::SymbolInfoInteger(strSymbol, SYMBOL_FILLING_MODE);
   return((iFillingMode == 0 || (otfFilingType >= ORDER_FILLING_RETURN) || ((iFillingMode & (otfFilingType + 1)) != otfFilingType + 1)) ?
         (((steExeMode == SYMBOL_TRADE_EXECUTION_EXCHANGE) || (steExeMode == SYMBOL_TRADE_EXECUTION_INSTANT)) ?
           ORDER_FILLING_RETURN : ((iFillingMode == SYMBOL_FILLING_IOC) ? ORDER_FILLING_IOC : ORDER_FILLING_FOK)) :
          otfFilingType);
  
   #endif // __MQL5__
};

The function works really well. I checked it many times and there were no errors. But I still do not understand how the result is formed in this awful return, despite my own rather good experience. Moreover, fxsaber answered the question that he himself does not remember it.

Vitaly, tell me how this code works, if it's not too difficult for you and you "understand it in a couple of minutes" in this style !

I would "open parentheses" in return operator, replace all "questions" with if's and return found values through logical "or". Personally I'm annoyed with operator "question" at all. It yields exactly the same code as a similar if, but its readability is much worse.

[Vitaly Muzichenko]

Georgiy Merts:

I have my doubts about it.

Here is the actual code of my function, which returns execution type (code was suggested by fxsaber, for which I am very grateful to him):

The function works really well. I checked it many times and there were no errors. However I still do not understand how the result is formed in this horrible return, despite my own rather good experience. Moreover, fxsaber answered the question that he himself does not remember it.

Vitaly, tell me how this code works, if it's not too difficult for you, and you "understand it in a couple of minutes" in this style !

I'd "open parentheses" in return operator, replace all "question" with if's and return found values via logical "or". Personally I'm annoyed with "question" operator at all. It yields exactly the same code as a similar if, but its readability is much worse.

I won't interpret the code, but I once posted a piece from my template, and there's a similar approach. I don't like stretching ifs into two scrolls of the monitor

[fxsaber]

Реter Konow:

do not forget aboutwork productivity. It starts with the readability of the code.

An example of my code, which right now I don't understand at all. And there are a lot of factors you need to understand very well.

Forum on trading, automated trading systems and strategy testing

Sequence of execution of Init() and DeInit()

fxsaber, 2017.04.14 23:35

  bool Check( void ) const
  {
    static bool FirstRun = true;
    static bool FirstRunInit = true;

    if (FirstRun && (!::GlobalVariableCheck(this.GlobalName)))
    {
      FirstRun = (::GlobalVariableSet(this.GlobalName, 0) == 0);

      if (!FirstRun)
      {
        ::EventKillTimer();

        ::OnInit();
        FirstRunInit = false;
      }
    }
    else if (FirstRun)
      ::EventSetMillisecondTimer(1);
    else
      FirstRunInit = true;

    return(FirstRun || !FirstRunInit);
  }

As you can see, the code/style is very simple. But I will only be able to detect an error in it or its absence when I can re-write the same code. It will really take a lot of time, as I need to fully understand the problem.

That's why the principle is that complex things are cleaned up (stress tests are written) at the creation stage and used in a simple form by plugging in mqh. As you can see, complexity is not always determined by style or brevity.

There is also an example of purely linguistic constructs - TypeToBytes. The comprehension complexity there is quite a different level. And this is where I would wither away without macros. It is because of macros that you get into the source code quite quickly. Because macros are often used not for brevity, but for comprehension.

And there's also the case when you have to consider a lot of uncomplicated but forgettable pitfalls. This is the case with MT4Orders. That's why some lines there are accompanied by comments addressed only to oneself. It helps to understand your code.

But note that these are all mqh, which you don't need to get into. And TC's code is written with mqh, which is very simple. You do not look into source code of regular iHigh functions. And they are monster indeed. You just use them. You should do the same with libraries. The same Generic-bibble to use doesn't require you to fully understand it.

Look at the QB for MT4 EAs and their MT5 ports. MT5 ports are a gimp to understand. Not only does it not smell close to conciseness (the code is many times larger than the original), but it also comes with rattling MT5 pitfalls that are not accounted for in the mqh-files.

[Georgiy Merts]

Vitaly Muzichenko:

I won't interpret the code, but I once posted a piece from my template, and there's a similar approach. I don't like stretching ifs into two monitor scrolls

In this case, it's wise to use functions.

And the fact that you didn't interpret the code says that you can't figure out how it works right away either. You have to thoroughly analyze parentheses, those very "questions" and logical "or". But such "piling up" is acceptable in very limited cases, when it gives more efficient code to be used in the "bottle neck" of the program. In this case, getting the execution type can't be a bottleneck and such code is undesirable here. I use it solely based on fxsaber's authority and repeated self-testing. But, this is an exception. As a rule, I don't use code that I haven't figured out in detail myself.

[fxsaber]

Georgiy Merts:

The function really works well. I checked it many times, no errors occurred. But I still don't understand how the result is formed in this horrible return, despite my, in my opinion, good enough experience. Moreover, fxsaber himself answered the question that he does not remember it himself.

It is not about returnee. If you describe the same logic in the form of if-else, it will not make me understand it any better. This is exactly the case when you take the "Unsupported filling" problem and study it very deeply. You have to write a lot of associated stress code, open a lot of accounts on different torus servers and race through all the symbols. Finding patterns among different combinations of flags. And finally, to bring all the tables to the same denominator. This is where the "can't remember" comes in.

Achieved that the problem no longer occurs and safely forgotten. It's great when you don't have to go back to once written code. It works - the main thing.