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

I highly recommend building with the setting to treat warnings as errors. This will cause the project to stop building, of course, but it's the only way to enforce a reasonable error policy.

Once you've done that, you can examine the warnings you have and make some reasonable decisions. There are probably some warnings that are benign and which you don't care about, so add these to the list of warnings to ignore. Fix the rest of them. If you don't have time to fix them all now, add a #pragma (or the C# equiv) to ignore the specific warnings that occur in every file, and file a bug for each of these to make sure they are addressed later.

In our development team, each person needs to clean up their warnings before beer o'clock on Friday. If you do not fix your warnings - no beer for you. It is surprisingly a good motivator.

Last fall I inheritied a new 5,000 line Java subsystem that had 100 ignored warnings. Like the other respondents here, my policy is to fix every warning, and in doing so, I found that three of the 100 were true programming errors. Warnings are there for a reason, so don't ignore them, fix them.

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

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

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

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

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

Best practices are to fix them all together. You should fix the ones that you have now, it may seem like it will take some time but they are usually little syntax errors that can be fixed easily. Then when you start getting them when you create more code you can just fix the ones that come up as you go.

I also always keep my projects on warning level 4, which is the highest level of warnings, so that when i compile i can fix everything that the default compiler (visual studios) thinks is wrong.

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

While programming you'll encouter so much problems, which won't be capture by compile-time (the evil run-time errors). So the compiler isn't capable to find all problems (aka errors). In some case he just says, mmmh there could be a problem, but i don't really know, please check it (aka warning). So take a look at the warning, fix it and proceed.

In some rare cases you really know what you do and just think, i know this warning, but this code is correct so don't bother me anymore. In these (really rare) cases, you could maybe encapsulate the line(s) which are mentioned with a

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

and proceed and the compiler doesn't mention anymore.

Hence take a look at all warnings and fix them. Either by reprogram it or by temporary disable this warning.

P.S. Really don't disable a warning within your project settings. Cause in this case you would disable it globally (and so maybe for code that will be created in the future) nor you can't add any comment why you disabled it.

Programmer smoking

A guy is standing on the corner of the street smoking one cigarette after another. A lady walking by notices him and says

“Hey, don’t you know that those things can kill you? I mean, didn’t you see the giant warning on the box?!”

“That’s OK” says the guy, puffing casually “I’m a computer programmer”

“So? What’s that got to do with anything?”

“We don’t care about warnings. We only care about errors.”

;)

My suggestion is ignore until you get the solution working perfectly. Then move to fixing the warnings; since the industry is "Deadline oriented" in most cases.;)

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

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

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

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

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

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

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

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

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

What I actually do: My current project also generates 30-40 warnings, and I ignore them.

What I should do: Fix them, because some of them might be meaningful.