Discussion of article "Using Assertions in MQL5 Programs" - page 2

New comment
 
Sergey Eremin:

For TEST_TEXT to be really easy to remove by conditional compilation, I would consider moving the Prints inside the macro. In the current version, I think it is easy to remove TEST_TEXT, but not the Prints themselves.

Yes, Sergey, I have thought about that. However, maybe I just haven't thought about it much and haven't "got to it" yet.

Simply, depending on the situation and comment(), for example, Alert( ) can be used as a source of test information output (in order to have a prompt notification about something without the need to look at the lines and if, among other things, it is not annoying and/or it is known that it will not "part") instead of Print().

That's why for the time being I've proceeded from the following:

  • if #define c keywords are put in the code, it is enough to comment out or delete #define;
  • if #define with keywords is put in an include file, it is enough to comment or delete the line about the include file (I probably like the option with the include file better),

and then the compiler will quickly tell you about the lines that have become inoperative. And even if you apply the search, you can completely comment out lines that are not required at the moment by pressing a button in the MetaEditor panel.

But I agree that it is better to have some universal variant available.

 
Dina Paches:
Yes, Sergey, I thought about it. However, maybe I just haven't thought about it much and haven't "got my hands on it" yet.

It's just that depending on the situation and comment(), for example, Alert( ) can be used as a source of test information output (if, among other things, it's not annoying) instead of Print().

So for now I'm assuming that:

  • if #define c keywords are put in code, it is enough to comment out or delete #define;
  • if #define with keywords is put in an include file, it is enough to comment or delete the line about the include file (I probably like the option with the include file better),

and then the compiler will quickly tell you about the lines that have become inoperative.

But to form some universal variant of course, I agree, is better.

In principle, yes, this approach helps to completely clean the code from irrelevant Prints. It's true, how many times it happened that you don't seem to need it, and then in a couple of months you need it again :)

But for such a case, you can try rolling back to the required version from git/svn (as a special case of svn - MQL5 Storage), but with reservations (by rolling back one thing, we can lose relevance in another).

 
Sergey Eremin:

In principle, yes, this approach helps to completely clean the code from irrelevant Prints. However, it has happened many times that you don't seem to need it anymore, and then a couple of months later you need it again :)

But for such a case you can try to rollback to the required version from git/svn (as a special case of svn - MQL5 Storage), but with reservations (by rolling back one thing, we can lose relevance in another).

Not having seen your reply yet, I added to my post to clarify it. But in terms of meaning, it remains the same and is not in opposition to what you have said.

Yes..., you are right, after some time it is necessary again). And those lines have already been "cleaned up" in the working version and rolling back to earlier ones really may not always be reasonable.

 
Sergey Eremin:
But in principle, if necessary, the number of "test" checks can still be obviously less than when constructing the code from scratch. But again, this is judging from the point of view of a person who writes the code himself and then refines/modifies it himself. That is, a rather narrow view.
 
Sergey Eremin:

P./S.: I would like to clarify that I meant not by "Search...", but by "Go to a given line" or "List of functions in a file".

P./S.: But coming back to the article, once again, the ability to apply statements like you cite in the article was very interesting. Thanks.

 
Dina Paches:

At the same time, having downloaded the file assert.mqh, I added a line to it:

And then in the code it looks like this:

  Print(TEST_TEXT,"a = ",a);

That is, that and simply when constructing the code to apply the output of information with the expectation that by the end of work on the code then this output of "working" information can be easily removed (as many, I believe, probably did and do with the output of information at the stages of code construction).

You may also find this macro useful

#define  PRINT(x)  Print(#x,"=",x)
//+------------------------------------------------------------------+
//| Script programme start function|
//+------------------------------------------------------------------+
void OnStart()
  {
//---
   PRINT(ORDER_TYPE_BUY_STOP_LIMIT);
   PRINT(ORDER_TYPE_SELL_STOP_LIMIT);
   PRINT(ORDER_POSITION_ID);
   PRINT(POSITION_TYPE_BUY);
   PRINT(POSITION_TYPE_SELL);
   
   PRINT(POSITION_TIME);
   PRINT(POSITION_TIME_MSC);
   PRINT(POSITION_TIME_UPDATE);
   PRINT(POSITION_TIME_UPDATE_MSC);
   PRINT(POSITION_TYPE);
   PRINT(POSITION_MAGIC);
   PRINT(POSITION_IDENTIFIER);
 
Rashid Umarov:

You may also find this macro useful

By the way, I think it would be good to add documentation about # and multiline macros. Those who have not learnt C may be a bit confused by the codes in the article and comments :)
 
Rashid Umarov:

This macro may be useful

Not possible, but really such a thing is necessary in the household. Thank you.

You give a good basis on which you can build up the "meat". Among other things, once again confirming that the genius is simple.

And, I suppose, Sergei probably meant something like this when he wrote here.

However, I still need to understand/familiarise myself with many things in relation to such constructions.

Among other things, when applying data transformation before printing (and taking into account printing not only via Print, but also in a comment or alert). And so that the variable name is not lost visually against DoubleToString, for example, or TimeToString.

That is, for example, I have written it like this now:

#define  TEST_PRINT(x)   Print(__LINE__,", ",__FUNCTION__,", ",#x,"=",x)
#define  TEST_COMMENT(x) Comment(__LINE__,", ",__FUNCTION__,", ",#x,"=",x)
#define  TEST_ALERT(x)   Alert(__LINE__,", ",__FUNCTION__,", ",#x,"=",x)

In the Experts tab, it is displayed like this:


And on the chart the same comment, in case of application.

That is, the price_0 variable is "lost" against DoubleToString.

However, it is already easier to do in the code with such #define output of test strings than I gave here earlier. Although it's still not the best option yet.


P./S.: Now I thought that the fact that the application of transforming functions is also output and clearly visible in the test text - this, on the contrary, may be useful. In general, it is not so much that the variable name is lost. It's just that earlier it wasn't supposed for myself and it's not usual for the eyes when outputting information.


Sergey Eremin:
By the way, I think it would be good to add documentation about # and multiline macros. Those who have not learnt C may be a bit confused by the codes in the article and comments :).
That would be great.
 
P./S.: Now the more I look at the output, the more I realise that, yes, the output and functions that convert data from one format to another are definitely convenient in test records. It's just a matter of optimising this as much as possible.
 
Andrey Shpilev:

1. Why macros? They are inconvenient, not all conditions can be fed to them, and it is extremely difficult to debug them if something goes wrong. It was easier to implement trivial procedures.

This is the case when macros are the only alternative.
123
New comment