Привет. Решил узнать, существуют ли какие-либо приемы трассировки и ассертов, которые не портили бы читабельность кода.
Вот кусок кода, до использования:
...
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);
}
Читабельность в разы падает =(
Re: Ухудшение читабельности при использовании trace и assert
Здравствуйте, BokiyIS, Вы писали:
BIS>Привет. Решил узнать, существуют ли какие-либо приемы трассировки и ассертов, которые не портили бы читабельность кода.
Да, для этого надо и трассировку и asserts писать в рамках какой-то продуманной стратегии.
Например, assert удобно использовать для записи инвариантов циклов, пред и постусловий функций и прочих ограничений, накладываемых кодом на состояние программы...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: Ухудшение читабельности при использовании trace и assert
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 будет писать сам.
Re[2]: Ухудшение читабельности при использовании trace и ass
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, BokiyIS, Вы писали:
BIS>>Привет. Решил узнать, существуют ли какие-либо приемы трассировки и ассертов, которые не портили бы читабельность кода.
E>Да, для этого надо и трассировку и asserts писать в рамках какой-то продуманной стратегии. E>Например, assert удобно использовать для записи инвариантов циклов, пред и постусловий функций и прочих ограничений, накладываемых кодом на состояние программы...
Спасибо. Но хотел бы заметить, что в таком случае пострадает информативность трейса.
Re[2]: Ухудшение читабельности при использовании trace и ass
Здравствуйте, no4, Вы писали:
no4>80 процентов повторяется — надо вынести в отдельный метод, который будет получать индивидуальные параметры, а всякие Thread.CurrentThread.ManagedThreadId будет писать сам.
В данном случае вы правы, но не всегда все трейсы подпадают под один и тот же шаблон.
Re: Ухудшение читабельности при использовании trace и assert
Здравствуйте, BokiyIS, Вы писали:
BIS>Привет. Решил узнать, существуют ли какие-либо приемы трассировки и ассертов, которые не портили бы читабельность кода.
Здравствуйте, BokiyIS, Вы писали:
E>>Да, для этого надо и трассировку и asserts писать в рамках какой-то продуманной стратегии. BIS>Спасибо. Но хотел бы заметить, что в таком случае пострадает информативность трейса.
Почему? Я про трейсы не писал, на самом деле, а только про asserts... Но как продуманность стратегии логгирования может испортить его информативность? Просто логи надо продуманные писать, а не фиксировать все изменения в состоянии программы.
Кстати, есть ещё и такой подход хитрый, что можифицируешь assert так, что он ещё и пишет в лог всё подряд, что есть в его выражении. И получаешь трейс подробный и отключаемый и на халяву...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: Ухудшение читабельности при использовании trace и ass
Здравствуйте, BokiyIS, Вы писали:
BIS>В данном случае вы правы, но не всегда все трейсы подпадают под один и тот же шаблон.
Дык потому систему логгирования тоже надо ПРОЕКТИРОВАТЬ!!!
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[2]: Ухудшение читабельности при использовании trace и ass
Здравствуйте, no4, Вы писали:
no4>80 процентов повторяется — надо вынести в отдельный метод, который будет получать индивидуальные параметры, а всякие Thread.CurrentThread.ManagedThreadId будет писать сам.
Даже ещё лучше, ThreadId должен уметь писать любой листенер (компонент который непосредственно выводит куда-либо данные) и настраивать вывод этого и других простых параметров (как время) можно извне с помощью файла конфигурации.
Help will always be given at Hogwarts to those who ask for it.
Re: Ухудшение читабельности при использовании trace и assert
Здравствуйте, BokiyIS, Вы писали:
BIS>Привет. Решил узнать, существуют ли какие-либо приемы трассировки и ассертов, которые не портили бы читабельность кода.
Присоединяюсь к тому, что сказал Егор, но на всякй случай от себя добавлю, что при использовании хорошего редактора всё, что относится к логированию и ассертам, можно просто выводить другим бледненьким цветом.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, BokiyIS, Вы писали:
BIS>>В данном случае вы правы, но не всегда все трейсы подпадают под один и тот же шаблон. E>Дык потому систему логгирования тоже надо ПРОЕКТИРОВАТЬ!!!
Спасибо. А случаем не подскажите, где можно почитать о стратегиях логирования и как его лучше организовать?
Хотелось бы просто посмотреть на best practices.
Re: Ухудшение читабельности при использовании trace и assert
Но тут надо понимать, что если трассировку можно убрать совсем
из кода, то ассерты всё же надо где-то писать. Можно писать
в коде в конкретных местах, что-то можно выносить в определённые
секции (например, в специальный кусок кода, который будет вызываться
перед каждым методом, или после каждого метода). Но выносить
так можно далеко не всё: если нужны какие-то асерты внутри
какого-то алгоритма, их придётся держать именно там в какой-либо
форме, более или менее мешающей основному коду.
Posted via RSDN NNTP Server 2.1 beta
Re: Ухудшение читабельности при использовании trace и assert
Здравствуйте, BokiyIS, Вы писали:
BIS>Привет. Решил узнать, существуют ли какие-либо приемы трассировки и ассертов, которые не портили бы читабельность кода.
Если ассерт не повышает читабельность, то это какой-то "неправильный" ассерт...
Re[3]: Ухудшение читабельности при использовании trace и ass
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.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re: Ухудшение читабельности при использовании trace и assert
Уменьшить эффект падения читабельности можно, внеся некоторые изменения в стиль кодирования. Если раньше было правило "Каждая строка кода должна быть не длиннее 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);
}
Re[2]: Ухудшение читабельности при использовании trace и ass
Здравствуйте, klopodav, Вы писали:
K>Получится вот так:
А распечатки?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: Ухудшение читабельности при использовании trace и ass
Ну, распечатается длинная строка с автопереносом — ничего страшного. Читабельность, конечно, будет хуже, чем с экрана, но всяко лучше, чем в первоначальном варианте.
Тем более что все-таки большую часть времени люди читают исходники с экрана, а не с распечатки
P.S. Если фрагмент исходников обрабатывается специально под распечатку, например для книги, то оттуда все равно придется ассерты и трейсы вручную убирать