Рекомендации по обработке предупреждений

Question

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

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

Answer 1

Есть только 30 из них, это 2 часа работы человека, только исправить их.

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

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

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

Answer 2

Что я на самом деле делаю: Мой текущий проект также генерирует 30-40 предупреждений, и я игнорирую их.

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Answer 6

Программист копчение

Мужик стоит на углу улицы курил одну сигарету за другой. Леди гуляет, замечая его и говорит:

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

„Это нормально“, говорит парень, пыхтя небрежно„Я программист“

«Ну и что? Что это значит? »

« Мы не заботимся о предупреждениях. Мы заботимся только об ошибках «

;.)

Мое предложение будет игнорировать, пока вы не получите решение работает отлично. Затем перейдите к фиксации предупреждений; поскольку в большинстве случаев индустрия «ориентирована на конечный результат»;)

Answer 7

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

Answer 8

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

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

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

Answer 9

Только представьте, что ваш проект - это автомобиль.

Что бы вы сделали, если в любое время, когда вы запустите свой автомобиль, мигают сигнальные лампы 30-40?

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

Мы используем некоторые статические анализаторы кода lime PMD или findBugs (оба для Java). После каждой сборки мы также фиксируем предупреждения, предоставляемые этими инструментами.

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

Answer 10

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

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

Answer 11

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

Answer 12

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

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

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

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

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

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

Answer 13

---

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

---

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

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

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