Обсуждение статьи "Использование утверждений (assertions) при разработке программ на MQL5" - страница 2

Новый комментарий
 
Sergey Eremin:

Для TEST_TEXT чтобы действительно было легко убирать условной компиляцией, я бы на Вашем месте рассмотрел вынос и Print'а внутрь макроса. В текущем варианте, мне кажется, легко убрать TEST_TEXT, но не сами Print'ы.

Да, Сергей, думала о таком. Однако пока может просто мало думала об этом и не "доходили до этого руки".

Просто в качестве источника вывода тестовой инфы в зависимости от ситуации и comment(), к примеру, может применяться и Alert() (чтоб иметь оперативное оповещение о чём-либо, без необходимости всматриваться в строки и если попутно, в том числе, он не раздражает и/или заведомо известно, что не будет "частить"), вместо Print().

Поэтому пока исходила и исхожу из того, что:

  • если #define c ключевыми словами ставить в коде, то достаточно закомментировать или удалить #define;
  • если #define c ключевыми словами ставить во включаемом файле, то достаточно закомментировать или удалить строку о включаемом файле (вариант с включаемым файлом мне, наверное, больше нравится),

и далее компилятор быстро подскажет о ставших не рабочими строках. Да и применив поиск, можно полностью закомментировать не требуемые в данный момент одним нажатием кнопки в панели MetaEditor.

Но иметь в наличии какой-то универсальный вариант конечно, согласна, лучше.

 
Dina Paches:
Да, Сергей, думала о таком. Однако пока может просто мало думала об этом и не "доходили до этого руки".

Просто в качестве источника вывода тестовой инфы в зависимости от ситуации и comment(), к примеру, может применяться и Alert() (если, в том числе, не раздражает), вместо Print().

Поэтому пока исхожу из того, что:

  • если #define c ключевыми словами ставить в коде, то достаточно закомментировать или удалить #define;
  • если #define c ключевыми словами ставить во включаемом файле, то достаточно закомментировать или удалить строку о включаемом файле (вариант с включаемым файлом мне, наверное, больше нравится),

и далее компилятор быстро подскажет о ставших не рабочими строках.

Но сформировать какой-то универсальный вариант конечно, согласна, лучше.

В принципе да, такой подход помогает полностью вычистить код от ставших неактуальными Print'ов. Правда, сколько раз случалось такое, что вроде не нужно оно уже, а потом через пару месяцев снова всё нужно :)

Но для такого такого случая можно попробовать откат до нужной версии из git/svn (как частный случай svn - MQL5 Storage), но с оговорками (откатив одно, мы можем потерять актуальность в другом).

 
Sergey Eremin:

В принципе да, такой подход помогает полностью вычистить код от ставших неактуальными Print'ов. Правда, сколько раз случалось такое, что вроде не нужно оно уже, а потом через пару месяцев снова всё нужно :)

Но для такого такого случая можно попробовать откат до нужной версии из git/svn (как частный случай svn - MQL5 Storage), но с оговорками (откатив одно, мы можем потерять актуальность в другом).

Не видя ещё ваш ответ, дополнила свой пост, уточняя. Но по смыслу он тот же остался и не в противовес вами далее сказанному.

Да..., вы правы, через какое-то время снова бывает нужно.) А строки те уже "подчищены" в рабочей версии и откат на более ранние действительно не всегда может быть целесообразен.

 
Sergey Eremin:
Но в принципе, при необходимости, в последующем количество "тестовых" проверок всё равно может быть заведомо меньше, чем при конструировании кода "с нуля". Хотя опять же, это ведь сужу с точки зрения человека, который сам пишет код и сам потом его дорабатывает/изменяет. То есть, довольно узкий взгляд.
 
Sergey Eremin:

P./S.: Уточню ещё, что про поиск для только пока закомментировать не требуемые в данный момент (ещё до окончательного вычищения тестовых строк из кода), имела в виду не по "Поиск...", а по "Переходу к заданной строке" или "Списку функций в файле".

P./S.: Однако возвращаясь к статье, ещё раз всё-таки скажу, что возможность применять утверждения, как приводите в статье, было очень интересным. Спасибо.

 
Dina Paches:

Заодно, скачав файл assert.mqh, добавила туда себе до кучи строчку:

А в коде потом это, соответственно, примерно так выглядит:

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

То есть, что и просто при конструировании кода применять вывод информации с расчётом на то, что к завершению работы над кодом потом этот вывод "рабочей" инфы легко убрать (как и многие, полагаю, наверное так делали и делают с выводом инфы на этапах конструирования кода).

Возможно, пригодится и такой макрос

#define PRINT(x)  Print(#x,"=",x)
//+------------------------------------------------------------------+
//| Script program 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:

Возможно, пригодится и такой макрос

Кстати, считаю, что было бы неплохо дополнить документацию про # и про многострочные макросы. Кто Си не учил, того могут немножко обескуражить коды в статье и комментариях :)
 
Rashid Umarov:

Возможно, пригодится и такой макрос

Не возможно, а действительно такое нужнО в хозяйстве. Спасибо.

Вы даёте хорошую основу, на которую  можно нарастить и "мясо". В том числе, в очередной раз подтверждая, что гениальное просто.

И, предполагаю, видимо, и Сергей имел в виду что-то наподобие такого, когда писал здесь.

Однако мне ещё надо для самой себя со многим разобраться/знакомиться применительно таких построений.

В том числе, при применении преобразования данных перед выводом на печать (и с учётом вывода на печать не только через Print, но и в комментарий или алерт). И чтобы название переменной не терялось визуально на фоне DoubleToString, к примеру, или TimeToString.

То есть, сейчас записала,  к примеру, так:

#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)

Во вкладке "Эксперты" это отображается так:


А на чарте такой же коммент, в случае применения.

То есть, переменная price_0 "теряется" на фоне DoubleToString.

Однако делать в коде с таким #define вывод тестовых строк уже проще, чем я приводила здесь ранее. Хотя пока это всё равно не будет ещё оптимальным вариантом.


P./S.: Сейчас подумалось, что то, что и применение преобразующих функций выводится и наглядно видно в тестовом тексте - это, наоборот, может быть полезным. В общем, не настолько сильно наименование переменной и теряется. Просто ранее для себя это не предполагалось и не привычно для глаз при выводе инфы.


Sergey Eremin:
Кстати, считаю, что было бы неплохо дополнить документацию про # и про многострочные макросы. Кто Си не учил, того могут немножко обескуражить коды в статье и комментариях :)
Это было бы здорово.
 
P./S.: Сейчас чем больше смотрю на вывод инфы, тем больше осознаю, что, да, вывод и функций, преобразующих данные из одного формата в другой - это однозначно удобно всё-таки в тестовых записях. Дело "за малым" - оптимизировать, по возможности, и это.
 
Andrey Shpilev:

1. Почему макросы? Они же неудобные, не все условия им можно скормить, и дебажить их крайне сложно, если что-то пойдет не так. Проще было банальные процедуры реализовать.

Тот случай когда макросы безальтернативный вариант
123
Новый комментарий
Причина обращения: