Features of the mql4 language, subtleties and techniques - page 12

New comment
 
Ihor Herasko:

In many software companies, code like this would get all their fingers beaten off. The first thing that is always and everywhere required is to avoid "unnecessary reading". For example, if you use a condition when entering a function:

then it is recommended to write:

This approach is a great help in avoiding the attachment of conditions.

Once again it is a pain in the ass. Because nobody checked what the OrderType() function returned. Or maybe it returned -1 or 6? This is an example of laying upon compiler's properties which you should always stay away from. You yourself cite many examples of cross-platform code. So why are you moving away from it in this case? A new MQ compiler will come out and this code will no longer work correctly.

With continue the same situation. Code like:

is harder to read than:

And yet the efficiency of execution is the same in both cases.

That's a total bummer:

if (!OrderSelect(i, SELECT_BY_POS))
   continue;

if (OrderSymbol() != Symbol())
   continue;

if (OrderMagicNumber() != m_nMagicNumber)
   continue;
 
Vitaly Muzichenko:

It's a total bummer, isn't it?

What's tinny? One line of a superexpression is where it gets tough. Humans are not computers, and they do not have to process the rest of the condition. A human, unlike a computer, has to compute the whole expression to the end and then only understand that its first component leads to a false result.

In an entry, where everything is decomposed by simple conditions, this calculation is unnecessary: the first condition is not fulfilled - gone.

You need to save time, not strings. But they just fight for brevity which is really a packing of operations and conditions into each other. If only this packing would give you a considerable productivity gain I could understand it. But it doesn't. The maximum growth is within the measurement error. People are concerned with saving strings but they don't think at all about saving time spent on understanding and debugging the code.

 
Ihor Herasko:

What's the tin? One line of super-expression - that's where it's tough. Humans are not computers, so they can immediately understand that they don't have to process the condition any further. A human, unlike a computer, has to compute the whole expression to the end and then only understand that its first component leads to a false result.

In an entry, where everything is decomposed by simple conditions, this calculation is unnecessary: the first condition is not fulfilled - gone.

You need to save time, not strings. But they just fight for brevity which is really a packing of operations and conditions into each other. If only this packing would give you a considerable productivity gain I could understand it. But it doesn't. The maximum growth is within the measurement error. People are concerned with saving strings but they don't think at all about saving time spent on understanding and debugging the code.

I wouldn't call it a hard-to-read super-expression.

if(!OrderSelect(i, SELECT_BY_POS) || OrderSymbol() != Symbol() || OrderMagicNumber() != m_nMagicNumber)
   continue;

Oh, and "short calculation cycle" is a basic thing that is "automatically" taken into account when reading a condition without requiring any mental effort to do so.

Again, purely subjective opinion.

 
Vladislav Boyko:

You yourself have agreed that it's a matter of habit.

And I'll say it again. I'm not encouraging anyone to change their habits and look for a difference in taste in felt-tip pens.

Igor Makanu:

As you said - it's a matter of taste, but as you know: all felt-tip pens are different ))))

Flock of felt-tip pens are different only in colour, they taste the same.
 
Vladislav Boyko:

I wouldn't call it a hard-to-read superlative.

And there is no need to call anything here. So far, my opponents (you included) have not made a single argument that this expression is easier to read than the line breakdown.

From me, however, as many as three arguments have been made:

  1. A long line doesn't fit in the field of view. Requires at least minimal head rotation (increases processing time). A short line and the one that follows it do not require that much effort.
  2. In a long line it is easier to make a mistake and not notice it. Splitting into lines decreases the probability of this kind of error.
  3. A long line is impossible to debug. Splitting it into strings is fine.
No subjective preferences. Everything is justified by practical sense and nothing more. Yes, some people may find it more convenient to scratch their left ear with the right heel but it doesn't mean that this approach is practical. In nature, everything is subject to practicality and those who are more practical survive.
 
Ihor Herasko:

And there is no need to name anything here. So far, my opponents (you included) have not made a single argument that this expression is easier to read than the line breakdown.

From me, however, as many as three arguments have been made:

  1. A long line doesn't fit in the field of view. Requires at least minimal head rotation (increases processing time). A short line and the one that follows it do not require that much effort.
  2. In a long line it is easier to make a mistake and not notice it. Splitting into lines decreases the probability of this kind of error.
  3. A long line is impossible to debug. Splitting it into strings is fine.
No subjective preferences. Everything is confirmed by practical sense and nothing more. Yes, some people may find it more convenient to scratch their left ear with the right heel but it doesn't mean that this approach is practical. And in nature, everything is subject to practicality and those who are more practical survive.

Igor, if the eyes don't move in the eye sockets and you have to turn your head, you can write like that:

if(OrderSelect(i, SELECT_BY_POS)
&& OrderSymbol() == _Symbol
&& OrderMagicNumber() == m_nMagicNumber)
 {
  // Делаем что надо...
 }

And how many short lines I've come across with errors........... Apparently, the number and probability of errors does not depend on the length of the line.

One can only agree with debugging. But the habit was developed before the debugger appeared in mql4 and not everyone is able to change the habits.

 
Alexey Viktorov:

Igor, if the eyes don't move in the eye sockets and you have to turn your head, you can write it that way:

And how many short lines I've come across with errors........... Apparently the number and probability of mistakes doesn't depend on the length of the line.

One can only agree with the debugging. But the habit has been developed before the debugger in mql4 and not everyone is able to change habits.

You can do it this way, but with this style to view one block of program you have to scroll the screen 2 times and this is worse than seeing all code in one screen. (Not concerning you, it's just an example).

 
fxsaber:

Unfortunately, this myth finds no support in the history of the forum. Moreover, the developers have consistently made clear their position that such changes cannot be made as a matter of principle.

There was such a thing. Sorting had an impact.

The discussion was probably held on the old metatrader4.com forum (still open recently, now it redirects to mql5.com).

 
Andrey Khatimlianskii:

It was like this. Sorting was affected.

The discussion must have been on the old metatrader4.com forum (still open recently, now redirecting to mql5.com).

It was, it was. Just like now with the number of historical orders, if you set "Today", then OrdersHistoryTotal() will return the number of closed orders that closed today. If the "History" tab does not show any old order, then it is not available even by ticket.

 
Alexey Viktorov:

It was, it was. Just like now with the number of historical orders, if you set "Today", OrdersHistoryTotal() will return the number of closed orders that closed today. If the "History" tab does not show any old order, then it is not available, even by ticket.

It's about sorting. Back then, if they weren't sorted by time, you couldn't find the last one by index - it was the last of the sorted ones.

And now the depth of history does not depend on selected tab? In my opinion, it still does.

1...5678910111213141516171819...36
New comment
Reason: