Проект, над которым я сейчас работаю, генерирует 30+ предупреждений каждый раз, когда он создается. Они были проигнорированы с самого начала проектов. Я думаю, из-за отсутствия политики в отношении предупреждений.
Как вы обычно справляетесь с этим? Игнорировать их вообще? Попробуйте исправить их все сразу (для этого требуется некоторое время)? Или просто побито по пути?
Есть только 30 из них, это 2 часа работы человек, просто исправить их.
Я полностью не согласен с тем, кто говорит, что срок истекает, фиксируя эти предупреждения. Вы будете тратить больше времени на то, чтобы переваривать проблемы на этапах завершения пост-кода, чем если бы вы исправили свои проблемы сейчас. Игнорируйте своего менеджера, он, вероятно, идиот, который хочет хорошо выглядеть своему боссу. Первоначальное качество и правильный дизайн более важны, чем его произвольные сроки (в пределах разумного). Тот факт, что у вас есть предупреждения в первую очередь, означает, что кто-то неаккуратно с кодом. Дважды проверьте области, в которых существуют предупреждения, для правильности.
Если вы используете анализ кода или пишете C/С++, тогда предупреждения иногда действительно недействительны. В этом случае прагма их (C/С++) или System.Diagnostics.CodeAnalysis.SuppressMessage. Это можно сделать автоматически с VS2008.
Я не видел никаких предупреждений .net, которые не были действительны вне анализа кода.
Я очень рекомендую строить с настройкой для обработки предупреждений как ошибок. Это, конечно, приведет к тому, что проект перестанет строиться, но это единственный способ обеспечить разумную политику ошибок.
Как только вы это сделаете, вы можете проверить предупреждения, которые у вас есть, и принять разумные решения. Вероятно, есть некоторые предупреждения, которые являются доброкачественными и которые вас не волнуют, поэтому добавьте их в список предупреждений, чтобы игнорировать. Исправьте остальные. Если у вас нет времени исправить их все сейчас, добавьте #pragma (или С# equiv), чтобы игнорировать конкретные предупреждения, возникающие в каждом файле, и записывать ошибку для каждого из них, чтобы убедиться, что они адресованы позже.
В нашей команде разработчиков каждый человек должен очистить свои предупреждения до пива в пятницу. Если вы не исправите свои предупреждения, вам не будет пива. Это удивительно хороший мотиватор.
Прошлой осенью я наследовал новую 5000-строчную подсистему Java, в которой было 100 игнорируемых предупреждений. Как и другие респонденты, моя политика заключается в том, чтобы исправить каждое предупреждение, и при этом я обнаружил, что три из 100 были истинными ошибками программирования. Предупреждения существуют по какой-то причине, поэтому не игнорируйте их, исправляйте их.
Большинство программистов регулярно создают свой код после написания каждой конструкции, чтобы убедиться, что она построена правильно. Это время, когда предупреждения отмечены (в VB, они также отмечены фоновой сборкой).
Я делаю это политикой для исправления предупреждений в каждой сборке. Я также не принимаю код из моей команды, который предупреждает о предупреждениях. Только очень немногие виды предупреждений являются "приемлемыми".
Итак, моя политика заключается в том, что вместо того, чтобы фиксировать их все вместе в более поздней точке, я исправляю их, поскольку они помечены. В качестве примечания, когда мой код начинает отмечать предупреждения, я рекомендую писать код, который не соответствует моим стандартам.
Каждое предупреждение должно быть исправлено или специально отключено (используя директиву компилятора или конструкцию кода, которая устраняет ее).
Если вы решите игнорировать предупреждение, не отключая его, все предупреждения становятся бессмысленными - потому что вы просто больше не смотрите на них. Вы знаете, что есть некоторые "хорошие" предупреждения, так зачем вообще смотреть на список?
Кроме того, настоятельно рекомендуется скомпилировать на самом высоком уровне предупреждения и "обрабатывать предупреждения как ошибки" (однако это делается вашим компилятором). Если ваш компилятор не поддерживает этот параметр, попробуйте выполнить его в любом случае, посмотрев его выходное/возвращаемое значение как часть сборки script/process.
Лучшие практики - исправить их все вместе. Вы должны исправить те, которые у вас есть сейчас, может показаться, что это займет некоторое время, но обычно это небольшие синтаксические ошибки, которые можно легко устранить. Затем, когда вы начинаете получать их, когда вы создаете больше кода, вы можете просто исправить те, которые появляются, когда вы идете.
Я также всегда сохраняю свои проекты на уровне 4-го уровня, который является самым высоким уровнем предупреждений, поэтому, когда я компилирую, я могу исправить все, что считается компилятором по умолчанию (visual studio).
Я также думаю, что вы должны исправить их все вместе, и после этого я рекомендую вам переключить настройку компилятора, чтобы обрабатывать все предупреждения как ошибки.
При программировании вы столкнетесь с таким количеством проблем, которые не будут выполняться во время компиляции (злые ошибки времени выполнения). Таким образом, компилятор не способен найти все проблемы (например, ошибки). В каком-то случае он просто говорит: mmmh может быть проблема, но я действительно не знаю, пожалуйста, проверьте это (ака предупреждение). Поэтому взгляните на предупреждение, исправьте его и продолжайте.
В некоторых редких случаях вы действительно знаете, что вы делаете, и просто подумайте, я знаю это предупреждение, но этот код верен, поэтому больше меня не беспокоить. В этих (действительно редких) случаях вы можете инкапсулировать строки (строки), которые упоминаются в
// Why you think this warning should be disabled at this point
#pragma warning disable xxx
/// ... some code ...
#pragma warning restore xxx
и продолжайте, и компилятор больше не упоминает.
Поэтому взгляните на все предупреждения и исправьте их. Либо перепрограммировать, либо временно отключить это предупреждение.
P.S. На самом деле не отключить предупреждение в настройках вашего проекта. Причина в этом случае вы бы отключили его глобально (и, возможно, для кода, который будет создан в будущем), и вы не можете добавить комментарий, почему вы его отключили.
Курение программистов
Парень стоит на углу улицы, куря одну сигарету за другой. Леди, идущая, замечает его и говорит"Эй, разве ты не знаешь, что эти вещи могут убить тебя? Я имею в виду, разве ты не видел гигантское предупреждение на коробке?"
"Это нормально" говорит парень, небрежно пыхтя "Я компьютерщик"
"Итак, что с этим связано?"
"Мы не заботимся о предупреждениях. Мы только заботимся об ошибках".
;)
Мое предложение игнорируется, пока вы не получите идеальное решение. Затем перейдите к фиксации предупреждений; поскольку в большинстве случаев отрасль "ориентирована на сроки".)
Представьте, что ваш проект - автомобиль.
Что бы вы сделали, если в любое время, когда вы запускаете свой автомобиль, мигают сигнальные лампы 30-40?
Если ваша сборка script сообщает вам, что должен по крайней мере посмотреть, что происходит, почему это предупреждение существует. Конечно, вы можете иметь примеры запущенных систем с предупреждениями, но это не то, что вы хотите (я ожидаю).
Мы используем некоторые статические анализаторы кода lime PMD или findBugs (как для Java). После каждой сборки мы также исправляем предупреждения, предоставляемые этими инструментами.
Если ваше предупреждение не имеет значения по какой-либо причине, тогда посмотрите, предоставляет ли ваш язык такие вещи, как @supressWarning. На самом деле это не рекомендация. Это только комментарий.
Кодекс намеренно, трава moker, как будто ваши предупреждения были развернуты на бумаге трейла. Хрупкий, как крылья бабочки, цепляясь за кокон из шелкового червя - когда вы можете закодировать его длину, эквивалентную печатным предупреждениям, и не оставлять никаких следов ошибок, вы будете лишены. --Master Poh
Если предупреждения, которые вы получаете, указывают на то, что вы не учли, вы должны продолжать обрабатывать предупреждения как ошибки и исправлять их немедленно.
Если предупреждения, которые вы получаете, всегда касаются того, что вы сделали специально, а сгенерированный код делает то, что вы намереваетесь, и время, затраченное на их исправление, не является незначительным, вы можете их игнорировать, но вам понадобятся новый ритуал для исправления ошибок.
Часть исправления теперь должна включать проверку каждой ошибки, чтобы увидеть, действительно ли какие-либо игнорируемые предупреждения действительно помечены этой ошибкой. Держите подсчитываемый счет. Пока игнорируемые предупреждения не помогли бы, продолжайте. Если/когда вы обнаружите, что вы проигнорировали два значимых предупреждения, вернитесь к рассмотрению всех предупреждений как ошибок. Дайте себе некоторое время для улучшения, а затем повторите попытку.
Что я на самом деле делаю: Мой текущий проект также генерирует 30-40 предупреждений, и я игнорирую их.
Что мне делать: исправить их, потому что некоторые из них могут быть значимыми.