Лучшие практики для обработки предупреждений

Question

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

Как вы обычно справляетесь с этим? Игнорировать их вообще? Попытаться исправить их все сразу (для этого нужно время)? Или просто исправить по ходу дела?

Answer 1

Их всего 30, это 2 часа работы, человек просто исправит их.

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

Если вы используете анализ кода или пишете на C / C ++, то предупреждения иногда действительно не действительны. В этом случае прагма их (C / C ++) или System.Diagnostics.CodeAnalysis.SuppressMessage. Это может быть сделано автоматически из VS2008.

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

Answer 2

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

После того, как вы это сделаете, вы можете изучить имеющиеся у вас предупреждения и принять некоторые разумные решения. Вероятно, есть некоторые предупреждения, которые являются доброкачественными и которые вас не волнуют, поэтому добавьте их в список предупреждений, чтобы их игнорировать. Исправьте остальные из них. Если у вас нет времени, чтобы исправить их все сейчас, добавьте #pragma (или эквивалент C #), чтобы игнорировать конкретные предупреждения, которые появляются в каждом файле, и отправьте сообщение об ошибке для каждого из них, чтобы убедиться, что они устранены позже.

Answer 3

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

Answer 4

Прошлой осенью я унаследовал новую 5000-строчную подсистему Java, в которой было 100 игнорируемых предупреждений. Как и другие респонденты, моя политика состоит в том, чтобы исправить каждое предупреждение, и при этом я обнаружил, что три из 100 были истинными ошибками программирования. Предупреждения существуют по какой-то причине, поэтому не игнорируйте их, исправьте их.

Answer 5

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

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

Answer 6

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

Я делаю политику исправления предупреждений при каждой сборке. Я также не принимаю код от моей команды, который помечает предупреждения. Только несколько видов предупреждений являются «приемлемыми».

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

Answer 7

Во время программирования вы будете сталкиваться с таким количеством проблем, которые не будут обнаружены во время компиляции (злые ошибки времени выполнения). Таким образом, компилятор не способен найти все проблемы (или ошибки). В некоторых случаях он просто говорит: «М-м-м-м-м, может быть проблема, но я не знаю, пожалуйста, проверьте это». Посмотрите на предупреждение, исправьте его и продолжайте.

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

// Why you think this warning should be disabled at this point
#pragma warning disable xxx
/// ... some code ...
#pragma warning restore xxx

и продолжайте, и компилятор больше не упоминает.

Поэтому посмотрите на все предупреждения и исправьте их. Либо перепрограммируйте его, либо временно отключите это предупреждение.

P.S. Действительно не отключите предупреждение в настройках вашего проекта. Потому что в этом случае вы бы отключили его глобально (и, возможно, для кода, который будет создан в будущем), и вы не можете добавить комментарий, почему вы его отключили.

Answer 8

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

Answer 9

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

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

Answer 10

---

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

---

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

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

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