Как сохранить свои собственные строки отладки, не проверяя их?

Question

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

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

Так как же локально сохранить важные для меня строки кода, не регистрируя их?

Пояснение: Многие ответы связаны с выводом журнала, и что вы с уровнями журнала можете отфильтровать это. И я согласен с этим.

Но. Я также упомянул проблему загрязнения самого кода. Если кто-то помещает оператор log между каждой другой строкой кода, все время печатать значение всех переменных. Это действительно делает код трудным для чтения. Поэтому я бы очень хотел этого избежать. В основном, не проверяя код регистрации вообще. Таким образом, вопрос заключается в следующем: как сохранить собственные строки журнала специального назначения. Таким образом, вы можете использовать их для отладочных сборок, не загромождая проверенный код.

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

Не уверен, какой источник контроля вы используете. С моим, вы можете легко получить список вещей, которые «ожидают проверки». И вы можете активировать коммит через API.

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

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

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

Answer 4

Если бы это действительно была постоянная проблема, я бы предположил, что центральный репозиторий является главной версией, и я бы в конечном итоге использовал файлы исправлений, чтобы содержать различия между официальной версией (последней, с которой я работал на) и моя версия с кодом отладки. Затем, когда мне нужно было восстановить отладку, я бы проверил официальную версию, применил свой патч (с помощью команды patch), исправил проблему, а перед регистрацией удалил патч с помощью patch -R ( перевернутый патч).

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

Answer 5

Почему бы не заключить их в директивы препроцессора (при условии, что конструкция существует на выбранном вами языке)?

#if DEBUG
    logger.debug("stuff I care about");
#endif

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

if(logger.isTraceEnabled()) {
    logger.log("My expensive logging operation");
}

Таким образом, если что-то в этой области возникнет однажды, вы можете снова включить ведение журнала на этом уровне и получить (надеюсь) полезную обратную связь. <Ч /> Обратите внимание, что оба эти решения по-прежнему позволяют регистрировать операторы регистрации, но я не вижу веской причины , а не , чтобы их проверяли. Я предоставляю решения, чтобы не допустить их в рабочие журналы .

Answer 6

Если вы действительно делаете что-то вроде:

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

вот в чем проблема. Попробуйте вместо этого использовать тестовую среду и напишите там код debug .

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

Answer 7

аналогично

#if DEBUG #endif....

Но это все равно будет означать, что любой, работающий с конфигурацией 'Debug', попадет на эти строки.

Если вы действительно хотите, чтобы они были пропущены, используйте уровень журнала, который никто другой не использует, или ....

Создайте другую конфигурацию запуска с именем MYDEBUGCONFIG. и затем поместите ваш код отладки между блоками, как это:

#if MYDEBUGCONFIG 
...your debugging code
#endif;

Answer 8

Какую систему контроля версий вы используете? Git позволяет вам хранить местные филиалы. Если хуже становится хуже, вы можете просто создать свою собственную ветку 'Andreas' в хранилище, хотя управление веткой может стать довольно болезненным.

Answer 9

Следующее предложение - безумие, не делай этого, но ты мог бы ...

Окружите свой личный код входа комментариями, такими как

// ##LOG-START##
logger.print("OOh A log statment");
// ##END-LOG##

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

Я бы на самом деле не рекомендовал это, потому что это мусорная идея, но это никогда никого не останавливает.

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

logger.print("My Innane log message"); //##LOG

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

Answer 10

ИМХО, вам следует избегать решения #if. Это способ C / C ++ для выполнения процедур условной отладки. Вместо этого приписывайте все функции ведения журнала / отладки с помощью ConditionalAttribute . Конструктор атрибута принимает строку. Этот метод вызывается только в том случае, если определено конкретное определение препроцессора с тем же именем, что и строка атрибута. Это имеет те же последствия во время выполнения, что и решение # if / # endif, но выглядит намного лучше в коде.