Должен ли я использовать класс Debug в .net?

Question

В последнее время я много читал о классе отладки .

Лично меня это очень волнует. Я вижу, как это улучшает процесс создания действительно сложных алгоритмов. Но это также добавляет много кода к моему приложению, которое мне приходится без необходимости просматривать. Наличие отладчика должно устранить необходимость в коде котельной пластины, независимо от того, будет ли он автоматически удален для сборки выпуска или нет?

Мне также интересно, как те из вас, кто действительно использует класс Debug, делают это. Вы вообще пишете операторы Debug.Assert или согласны с Эд Каимом , что Debug.WriteLine и Debug.Fail - это все, что вам нужно использовать.

Answer 1

Я лично согласен с Эдом Каимом. Лично я чувствую, что хорошие практики тестирования заменили вызовы Debug.Assert во всей моей работе. Кроме того, я в значительной степени отказался от использования Debug.Fail - каждый раз, когда я хочу использовать это, я в значительной степени обнаруживаю, что хочу вызвать исключение в выпуске, а также в отладке, поэтому я обычно не вижу точка.

При этом я все еще использую некоторые операторы печати отладки для расширения своей отладки (через Debug.WriteLine), особенно в числовом коде ... Я признаю, что это возврат к отладке старой школы printf, но часто это по-прежнему самый быстрый способ отследить проблему, особенно ту, которая не отображается в отладчике (из-за проблем с синхронизацией, многопоточности и т. д.).

Answer 2

Лично я вообще редко использую класс Debug для любого моего программирования. Я прочитал много комментариев и предложений, таких как Джон Роббинс (автор Отладка приложений .NET 2.0 и Bugslayer столбцы) о том, почему вы должны активно утверждать - особенно параметры для методов.

Проблема у меня заключается в следующем - скажем, я должен был написать код, подобный этому:

Public Sub Test(source As Object)

  Debug.Assert(source IsNot Nothing, "source is Nothing")

  ' Do something....
End Sub

Это хорошо работает во время разработки с отладочными сборками, но я все равно делаю это:

Public Sub Test(source As Object)

  If source IsNot Nothing Then

  ' Do something....

  End If
End Sub

Если есть шанс, что «источник» будет ничем, тогда я все равно сделаю проверку «Если». Я не собираюсь оставлять вызов assert в сборке релиза.

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

Что касается ведения журнала отладки, то я просто использую вызовы Trace и SysInternals DebugView или текстовые файлы для записи результатов вызовов трассировки.

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

Answer 3

Я бы предложил вообще не использовать класс Debug; Я не. Как правило, для разработки я нахожу, что отладчик достаточно хорош для всех моих потребностей; и что мне действительно нужно отслеживать, я регистрируюсь. Наиболее важной частью ведения журнала является то, что ведение журнала также происходит в рабочем коде , что может быть абсолютно важным. Debug по определению работает только в отладочном коде; хотя это может быть полезно, чтобы помочь вам найти что-то во время разработки, если это так важно найти, запишите это. Шутки в сторону. Если важно найти и достаточно сложно, чтобы вам понадобилось специальное средство, войдите в него; скорее всего, он появится в вашей производственной среде как крайний случай, и что вы будете тогда делать?

И что бы это ни стоило, я считаю, что log4net невероятно полезен и надежен для ведения журналов. Я бы порекомендовал его использовать вместо использования класса Debug в любой день.

Answer 4

Я не могу сказать вам, если вы должны, но я могу предложить времена, когда я его использую.

Я использую Debug, когда мне нужно больше информации о функции / переменной / процессе / результате, но я знаю, что когда она будет опубликована, информация больше не актуальна. Я использую Debug.Writeline, например, для проверки правильности хронологии процесса, или Debug.Assert, чтобы проверить, что значение должно быть таким.

Я думаю, что Каим просто говорит, что легко использовать Debug.Assert. Не используйте Debug.Assert для выявления проблем, которые могут возникнуть в работе. Debug.Assert предназначен для простых проверок во время разработки, таких как флаг напоминания. Он не предназначен для обработки ошибок кода выпуска. Вы можете поставить Debug.Assert на любую другую строку, не беспокоясь о том, что это замедляет выпуск кода.

Answer 5

Мое личное мнение таково, что Debug.Assert и Debug.Fail часто неправильно используют для «скрытия» ошибок от конечных пользователей. Я лучше напишу в журнал ошибок или сгенерирую исключение, если это оправдано.

Answer 6

Основным преимуществом использования класса Debug по сравнению с простым запуском кода в отладчике является то, что вы получаете файл журнала (с помощью операторов Debug.Writeline), который вы можете поделиться с коллегами / хранилищем для своих записей.

Преимуществами, которые Debug.Assert имеет по сравнению с написанием отдельного метода тестирования, является компактность и тот факт, что проверка находится именно там, где она должна быть, а не отдельным методом.

Answer 7

Debug.Assert тест для контракта. У него есть небольшое преимущество в том, что его нет в коде релиза. Это не относится к случаю исключения исключений if +.

Я использую Debug.WriteLine для событий пользовательского интерфейса, потому что там мешает отладчик (например, события обновления вызываются снова при переключении из окна VS в окно приложения).

Answer 8

Мы используем Debug.Assert очень часто - для каждого важного предположения, что вы сделаете это, не вредно иметь Assert.

Довольно полезная, но старая статья - IDesign C # Стандарты кодирования здесь