Привет. Решил узнать, существуют ли какие-либо приемы трассировки и ассертов, которые не портили бы читабельность кода.

Вот кусок кода, до использования:

...
           HandlingOperationStatus status =
                TransactionLogManager.GetHandlingStatus(TransactionsLog, this.Name);


            //we don't need to handle already completed operation.
            if (status == HandlingOperationStatus.Complete)
            {
               return;
            }
            //this code runs when handler was stop before it has time to
            //rollback.
            else if (status == HandlingOperationStatus.Running)
            {
               Rollback(TransactionsLog);
            }
...

а вот после:

            Debug.Assert(tfsEvent != null, "tfsEvent == null");

            Trace.WriteLine(string.Format("{0} handler {1} start handling {2} msg",
                    Thread.CurrentThread.ManagedThreadId,
                    this.Name, tfsEvent.MessageGuid));


            HandlingOperationStatus status =
                TransactionLogManager.GetHandlingStatus(TransactionsLog, this.Name);


            //we don't need to handle already completed operation.
            if (status == HandlingOperationStatus.Complete)
            {
                Trace.WriteLine(string.Format("{0} tfs event {1} was already " +
                    "handled by {2} handler", 
                    Thread.CurrentThread.ManagedThreadId,
                    tfsEvent.MessageGuid, this.Name));

                return;
            }
            //this code runs when handler was stop before it has time to
            //rollback.
            else if (status == HandlingOperationStatus.Running)
            {
                Trace.WriteLine(string.Format("{0} Rollback due to Running " + 
                    "status of {1}",
                    Thread.CurrentThread.ManagedThreadId,
                    tfsEvent.MessageGuid));

                Rollback(TransactionsLog);
            }

Читабельность в разы падает =(

Здравствуйте, BokiyIS, Вы писали:

BIS>Привет. Решил узнать, существуют ли какие-либо приемы трассировки и ассертов, которые не портили бы читабельность кода.

Да, для этого надо и трассировку и asserts писать в рамках какой-то продуманной стратегии.
Например, assert удобно использовать для записи инвариантов циклов, пред и постусловий функций и прочих ограничений, накладываемых кодом на состояние программы...

Здравствуйте, BokiyIS, Вы писали:

По моему большая избыточность:

 Trace.WriteLine(string.Format("{0} tfs event {1} was already " +
                    "handled by {2} handler", 
                    Thread.CurrentThread.ManagedThreadId,
                    tfsEvent.MessageGuid, this.Name));

80 процентов повторяется — надо вынести в отдельный метод, который будет получать индивидуальные параметры, а всякие Thread.CurrentThread.ManagedThreadId будет писать сам.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, BokiyIS, Вы писали:

BIS>>Привет. Решил узнать, существуют ли какие-либо приемы трассировки и ассертов, которые не портили бы читабельность кода.

E>Да, для этого надо и трассировку и asserts писать в рамках какой-то продуманной стратегии.
E>Например, assert удобно использовать для записи инвариантов циклов, пред и постусловий функций и прочих ограничений, накладываемых кодом на состояние программы...

Спасибо. Но хотел бы заметить, что в таком случае пострадает информативность трейса.

Здравствуйте, no4, Вы писали:

no4>80 процентов повторяется — надо вынести в отдельный метод, который будет получать индивидуальные параметры, а всякие Thread.CurrentThread.ManagedThreadId будет писать сам.

В данном случае вы правы, но не всегда все трейсы подпадают под один и тот же шаблон.

Здравствуйте, BokiyIS, Вы писали:

BIS>Привет. Решил узнать, существуют ли какие-либо приемы трассировки и ассертов, которые не портили бы читабельность кода.

Есть. Их надо не показывать.

Здравствуйте, mkizub, Вы писали:

M>Есть. Их надо не показывать.

Т.е.? Заворачивать в регионы? Или что вы имели в виду?

Здравствуйте, BokiyIS, Вы писали:

E>>Да, для этого надо и трассировку и asserts писать в рамках какой-то продуманной стратегии.
BIS>Спасибо. Но хотел бы заметить, что в таком случае пострадает информативность трейса.

Почему? Я про трейсы не писал, на самом деле, а только про asserts... Но как продуманность стратегии логгирования может испортить его информативность? Просто логи надо продуманные писать, а не фиксировать все изменения в состоянии программы.

Кстати, есть ещё и такой подход хитрый, что можифицируешь assert так, что он ещё и пишет в лог всё подряд, что есть в его выражении. И получаешь трейс подробный и отключаемый и на халяву...

Здравствуйте, BokiyIS, Вы писали:

BIS>В данном случае вы правы, но не всегда все трейсы подпадают под один и тот же шаблон.
Дык потому систему логгирования тоже надо ПРОЕКТИРОВАТЬ!!!

Здравствуйте, no4, Вы писали:

no4>80 процентов повторяется — надо вынести в отдельный метод, который будет получать индивидуальные параметры, а всякие Thread.CurrentThread.ManagedThreadId будет писать сам.

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

Здравствуйте, BokiyIS, Вы писали:

BIS>Привет. Решил узнать, существуют ли какие-либо приемы трассировки и ассертов, которые не портили бы читабельность кода.

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

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, BokiyIS, Вы писали:

BIS>>В данном случае вы правы, но не всегда все трейсы подпадают под один и тот же шаблон.
E>Дык потому систему логгирования тоже надо ПРОЕКТИРОВАТЬ!!!

Спасибо. А случаем не подскажите, где можно почитать о стратегиях логирования и как его лучше организовать?
Хотелось бы просто посмотреть на best practices.

BokiyIS wrote:

> Привет. Решил узнать, существуют ли какие-либо приемы трассировки и
> ассертов, которые не портили бы читабельность кода.

Существуют. Встроенные в язык средства: трассировки и ассертов.
Трассировка есть, например, в COMMON LISP. Ассерты тоже где-то
есть, то ли в Эйфеле, то ли ещё где.
(//http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D1%82%D1%80%D0%B0%D0%BA%D1%82%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)

Но тут надо понимать, что если трассировку можно убрать совсем
из кода, то ассерты всё же надо где-то писать. Можно писать
в коде в конкретных местах, что-то можно выносить в определённые
секции (например, в специальный кусок кода, который будет вызываться
перед каждым методом, или после каждого метода). Но выносить
так можно далеко не всё: если нужны какие-то асерты внутри
какого-то алгоритма, их придётся держать именно там в какой-либо
форме, более или менее мешающей основному коду.

Здравствуйте, BokiyIS, Вы писали:

BIS>Привет. Решил узнать, существуют ли какие-либо приемы трассировки и ассертов, которые не портили бы читабельность кода.

Если ассерт не повышает читабельность, то это какой-то "неправильный" ассерт...

Здравствуйте, BokiyIS, Вы писали:

M>>Есть. Их надо не показывать.

BIS>Т.е.? Заворачивать в регионы? Или что вы имели в виду?

Берёте редактор, который поддерживает folding и/или подсветку синтаксиса, задаёте ему правила для фолдинга или блеклого цвета для трейсов.

Здравствуйте, BokiyIS, Вы писали:

BIS>Привет. Решил узнать, существуют ли какие-либо приемы трассировки

Business Logic Toolkit — LoggingAspect

This aspect allows logging some diagnostic information with minimum efforts. All you need to do is to decorate your class with the Log attribute. If you have a class hierarchy you can decorate only your base class. Diagnostic information will be logged for all virtual and abstract members of your abstract class.

BIS>Читабельность в разы падает =(

Уменьшить эффект падения читабельности можно, внеся некоторые изменения в стиль кодирования. Если раньше было правило "Каждая строка кода должна быть не длиннее N символов", то вместо него сделать: "Обычная строка кода должна быть не длиннее N символов, а трейс всегда пишется в одну строку".
Почему это оправдано — потому что читающему код абсолютно пофиг, какие именно данные запишутся в трейс, ему достаточно видеть: "вот в этом месте записать в трейс нечто". И он, естественно, не будет использовать горизонтальную прокрутку, чтобы дочитать до конца строки — он просто эту строку пропустит и станет читать код дальше

Получится вот так:

            Debug.Assert(tfsEvent != null, "tfsEvent == null");

            Trace.WriteLine(string.Format("{0} handler {1} start handling {2} msg", Thread.CurrentThread.ManagedThreadId, this.Name, tfsEvent.MessageGuid));

            HandlingOperationStatus status =
                TransactionLogManager.GetHandlingStatus(TransactionsLog, this.Name);


            //we don't need to handle already completed operation.
            if (status == HandlingOperationStatus.Complete)
            {
                Trace.WriteLine(string.Format("{0} tfs event {1} was already " + "handled by {2} handler", Thread.CurrentThread.ManagedThreadId, tfsEvent.MessageGuid, this.Name));

                return;
            }
            //this code runs when handler was stop before it has time to
            //rollback.
            else if (status == HandlingOperationStatus.Running)
            {
                Trace.WriteLine(string.Format("{0} Rollback due to Running " + "status of {1}", Thread.CurrentThread.ManagedThreadId, tfsEvent.MessageGuid));

                Rollback(TransactionsLog);
            }

Здравствуйте, klopodav, Вы писали:

K>Получится вот так:
А распечатки?

K>>Получится вот так:
E>А распечатки?

Ну, распечатается длинная строка с автопереносом — ничего страшного. Читабельность, конечно, будет хуже, чем с экрана, но всяко лучше, чем в первоначальном варианте.
Тем более что все-таки большую часть времени люди читают исходники с экрана, а не с распечатки

P.S. Если фрагмент исходников обрабатывается специально под распечатку, например для книги, то оттуда все равно придется ассерты и трейсы вручную убирать