Должен ли код отладки оставаться на месте, всегда или добавляться только при отладке и удалении при обнаружении ошибки?

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

Как вы это делаете? Вы оставляете код отладки на месте или удаляете его, когда устарели (что может быть трудно судить, когда это так)?

31 голос | спросил gablin 3 Jam1000000amMon, 03 Jan 2011 01:34:24 +030011 2011, 01:34:24

8 ответов


27

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

ответил Alaric 3 Jam1000000amMon, 03 Jan 2011 01:53:12 +030011 2011, 01:53:12
14

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

Будет ли это полное удаление или помещено в секции условной компиляции (как в C /C ++ /C #), зависит от вас и вашего стандарта кодирования.

Для этого есть несколько причин:

  1. При выполнении этого кода могут возникнуть проблемы с безопасностью, или кто-то может получить доступ к его выходным файлам.
  2. Это может замедлить работу приложения.
  3. Это может смутить других разработчиков, которые смотрят на код (или действительно на себя) через 6 месяцев.
ответил ChrisF 3 Jam1000000amMon, 03 Jan 2011 01:40:42 +030011 2011, 01:40:42
12

ChrisF и Alaric имеют действительные баллы; +1 для них. Я могу определить по крайней мере 5 различных типов кода отладки, которые я использую.

  1. Использование журналов для сброса состояния системы в определенный момент времени.

    void function(...)
    {
        ...dump everything i know about.
    }
    
  2. Использование журналов для контрольных точек выполнения.

    void function(...)
    {
        ...got here 1
        ...got here 2
    }
    
  3. Код, который фактически заставляет определенное условие быть истинным, но нарушает нормальное поведение. Пример:

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

  5. Регистрация операций - см. сообщение Аларика . Это в значительной степени то, что я подразумеваю под «ведением журнала операций».

1, 2 и 3 следует вынимать полностью. Что-то вроде 4, я, вероятно, условно скомпилирую код. Для 5, Alaric имел отличную возможность динамически отключать журналы. Это может означать пункт ChrisF в его второй пуле для большинства случаев.

ответил Pemdas 3 Jam1000000amMon, 03 Jan 2011 04:23:27 +030011 2011, 04:23:27
2

Это зависит от того, что делает код. Некоторый код, который используется для отладки, может быть оставлен как есть, а некоторые должны быть удалены.

Код, который проверяет здравомыслие параметров в методе, не всегда полезен, как только код работает должным образом, но часто он должен следить за тем, чтобы код продолжал работать должным образом.

Иногда вы пишете код по-другому, чтобы упростить отладку кода, например, вычисляя значение и помещая его в локальную переменную, а затем используйте переменную в следующей строке, что позволяет легко проверить результат вычисления когда один шаг через код. Вы можете переписать код, чтобы использовать рассчитанное значение напрямую, но стоимость использования локальной переменной настолько мала (если вообще есть), что нет причин переписывать код. Кроме того, есть смысл оставить код неизменным после того, как вы его протестировали, всегда есть небольшой риск, что вы введете ошибку при ее изменении.

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

ответил Guffa 3 Jam1000000amMon, 03 Jan 2011 03:38:45 +030011 2011, 03:38:45
2

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

Некоторый код отладки остался на месте, в частности, материал, предназначенный для размещения вложенных вызовов. Тем не менее, несмотря на то, что строка отладки в основном не будет видна в производственной системе, все равно все это делается при условной компиляции.

Реальность заключается в том, что весь этот отладочный код был большим количеством усилий для чего-то, что идеально обрабатывается по-другому - используя, конечно, отладчик. В то время я не был впечатлен отладчиком Borland C ++. Инструменты были там, но они слишком часто приводили к вводящим в заблуждение результатам, а использование отладчика без IDE (часто необходимо) означало запоминание сочетаний клавиш, что означало отвлечение внимания на задание.

Единственный опыт отладки, который я обнаружил, хуже, это GDB командной строки.

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

К тому времени, когда я работал в Visual Studio 7, было ясно, что отладка может быть очень практичной и эффективной. Если вы можете выполнить отладку в Visual Studio (включая экспресс-выпуски), отладка - легкий ветерок. Несомненно, если вы можете найти нужный интерфейс GUI /IDE, GDB также прост и эффективен, хотя я еще не выполнил этот поиск.

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

Неожиданно важный инструмент = cmake, инструмент сборки, который позволяет мне легко переключаться между построением для GCC и VC ++, между прочим. Поэтому я могу выполнить модульное тестирование и использование gcov-покрытия с помощью GCC, но с легкостью переключитесь на VC ++, чтобы использовать отладчик.

ответил Steve314 3 Jam1000000amMon, 03 Jan 2011 04:06:33 +030011 2011, 04:06:33
2

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

ответил Loren Pechtel 3 Jam1000000amMon, 03 Jan 2011 08:14:05 +030011 2011, 08:14:05
0

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

ответил Manoj R 3 Jam1000000amMon, 03 Jan 2011 09:01:06 +030011 2011, 09:01:06
0

Используйте TDD , поэтому ваш тестовый код всегда имеет место, где он поддерживается.

ответил dukeofgaming 3 Jpm1000000pmMon, 03 Jan 2011 18:38:57 +030011 2011, 18:38:57

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132