Как последовательно организовать код для отладки?

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

Я бы избегал таких вещей, как макросы, просто потому, что это трюк компилятора, а не истинный объектно ориентированный объект. Абстрагируя концепцию отладки / ведения журнала, у вас есть возможность делать с ним много вещей, в том числе, при необходимости, отключать его.

Ведение журнала или отладка? Я считаю, что хорошо спроектированное и правильно протестированное приложение не должно постоянно оснащаться инструментами для отладки. С другой стороны, ведение журнала может быть очень полезным как для поиска ошибок, так и для аудита действий программы. Вместо того, чтобы описывать много информации, которую вы можете получить где-либо еще, я бы указал вам на logging.apache.org либо для конкретных реализаций, которые вы можете использовать, либо для шаблона для разумного дизайна инфраструктуры регистрации.

Я думаю, что особенно важно избегать прямого использования System.outs / printfs и вместо этого использовать (даже настраиваемый) класс ведения журнала. Это, по крайней мере, дает вам централизованный аварийный выключатель для всех журналов (за вычетом затрат на вызов в Java).

Также полезно иметь в этом классе журнала информацию / предупреждение / ошибку / предостережение и т. д.

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

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

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

Loggin OTOH занимает естественное место в процедурах обработки выполнения и тому подобном. Также для отладки могут быть полезны несколько хорошо размещенных статистических данных о журналах в нескольких часто используемых API.

Как один статус журнала для регистрации всего SQL, выполняемого из системы.

В VB6 у вас есть

Debug.Print

который отправляет вывод в окно в IDE. Для небольших проектов это терпимо. VB6 также имеет

#If <some var set in the project properties>
'debugging code
#End If

У меня есть класс ведения журнала, который я объявляю вверху с помощью

Dim Trc as Std.Traces

и использовать в разных местах (часто внутри блоков # If / # End If)

Trc.Tracing = True
Trc.Tracefile = "c:\temp\app.log"
Trc.Trace 'with no argument stores date stamp
Trc.Trace "Var = " & var

Да, это действительно беспорядочно, и да, я бы хотел, чтобы был лучший способ.

Обычно мы начинаем использовать статический класс, в который пишем сообщения трассировки. Это очень просто и по-прежнему требует вызова из исполняющего метода, но он служит нашей цели.

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

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

Просто избегайте инструментирования кода путем его модификации. Научитесь пользоваться отладчиком. Упростите ведение журнала и обработку ошибок. Взгляните на Аспектно-ориентированное программирование

Меня обжигала одна и та же проблема почти в каждом проекте, в котором я участвовал, поэтому теперь у меня есть эта привычка, которая включает в себя широкое использование библиотек журналов (независимо от языка / платформы) с самого начала. Любой Порт Log4X мне подходит.

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

Хотя это требует времени и усилий, в конечном итоге это может сэкономить вам много времени и нервов.