Интересный способ подавить вывод сообщения checkFailed

[S.Kuskov]

В общем, делюсь найденной мною фичей.
Известно, что x++ поддерживает написание локальных функции в области описания переменных.
Так же известно, что к методам описанным в классе Global можно обращаться без префикса в виде имени класса (в этом случае работа с ними выглядят так же как со встроенными функциями).
Так вот, оказывается имя локальной функции вполне может совпадать с именем метода класса Global. И тогда она его перекрывает своей областью видимости!
Данное поведение не распространяется на встроенные функции. Если имя такой локальной функции совпадёт с именем встроенной функции (например abs), то компилятор будет ругаться, не позволяя переопределить стандартную функцию.

Где это можно использовать? Я хочу продемонстрировать следующий приём.
Допустим у нас есть некий метод validate, который не просто делает некоторые проверки но и выводит в случае неудачи текст ошибки в инфолог. Скорее всего делает это он при помощи довольно популярного метода checkFailed класса Global.
Предположим, что нам понадобилось воспользоваться этим методом в тихом режиме. Т.е. мы хотим узнать выполнились ли проверки, но не хотим что бы при этом в случае ошибки сообщения выводились в инфолог. Простейшее решение - это добавить входной параметр со значением по умолчанию для совместимости с существующим кодом boolean _showError = true и использовать его для выбора варианта действия.
В случае если наш метод validate содержит несколько проверок, то модификации могут оказаться объёмными. Для того чтобы минимизировать количество правок кода я предлагаю перекрыть в рамках этого кода сам метод checkFailed.
Выглядит это так:

protected boolean validate(boolean _showError = true)
{
    boolean ret = true;
    // вместо модификации всего кода переопределяем в одном месте checkFailed
    // -->>
    boolean checkFailed(SysInfoLogStr txt)
    {
        return
            _showError
                ? Global::checkFailed(txt)
                : false;
    }
    // <<--
    // остальной код оставляем без изменений
    ;

    if (Fail1)
        ret = checkFailed("Error 1");
    if (Fail2)
        ret = checkFailed("Error 2");
    ...
    if (FailN)
        ret = checkFailed("Error N");

    return ret;
}

С одной стороны всё довольно-таки красиво получилось, а с другой стороны я раньше нигде не встречал подобного приёма. Как думаете?

[oip]

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

Собственно, повторяться не буду. Свою точку зрения на подобный фичи я уже много раз писал. Например вот в этой теме, пусть там речь и про другое: Вернуть this из класса

Цитата:

Сообщение от oip

Я тоже против таких наворотов. Код для непосвещенного перестает быть читабельным. И вместо того чтобы разбираться в бизнес-логике, человеку сначала придется разобраться в самом способе написания кода.

Цитата:

Сообщение от oip

Сделайте этот класс стандартом через майкрософт. Если М$ его официально включит в систему, если его все на всех проектах будут использовать - я что, против? А вот если каждый у себя на проекте будет использовать какую-то местную удобную по вашему мнению (а мнение других спросили, тех кто после вас поддерживать, дорабатывать, апгрейдить систему будет? Почему вы считаете, что если что-то удобно вам, то оно будет удобно всем остальным?) приблуду такого рода, то будет хаос. Появляется какое-то программирование ради программирования.

[Мартынов Дмитрий]

Цитата:

Сообщение от oip

...Затраты на поддержку такого кода будут существеннов выше пользы от него....

Это личные наблюдения? Или к этому можно добавить какие нибудь исследования или другие источники ? В бест практис например такого точно нет.....

[gl00mie]

Цитата:

Сообщение от Мартынов Дмитрий

Это личные наблюдения?

Если и личные наблюдения, то я готов присоединиться. Использование всяких, скажем так, неочевидных особенностей языка лишь затрудняет понимание и сопровождение кода, а это неминуемо ведет к повышению числа ошибок и/или повышению TCO.
Если где-то и нужно подавить вывод в инфолог, то в 99.9% случаев это будет вывод из вызываемых методов, где данный подход не сработает. В таких случаях проще временно выставить infologLevel в None. А для текущего метода куда "прямее" отрубать вывод в инфолог по if и значению переменной или параметра.

Цитата:

Сообщение от Мартынов Дмитрий

В бест практис например такого точно нет...

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

[blokva]

Цитата:

Сообщение от gl00mie

Если и личные наблюдения, то я готов присоединиться. Использование всяких, скажем так, неочевидных особенностей языка лишь затрудняет понимание и сопровождение кода, а это неминуемо ведет к повышению числа ошибок и/или повышению TCO.
Если где-то и нужно подавить вывод в инфолог, то в 99.9% случаев это будет вывод из вызываемых методов, где данный подход не сработает. В таких случаях проще временно выставить infologLevel в None. А для текущего метода куда "прямее" отрубать вывод в инфолог по if и значению переменной или параметра.К сожалению, Best Practices не способны заменить здравый смысл, и на все случаи жизни их не напасешься.

Вообще-то от большинства подобных проблем спасают комментарии. Особенно, при использовании "неочевидных" решений.
2oip вот за отсутствие комментариев в подобных случаях и надо "бить по рукам"