一般来说，我应该将我的编译器设置为将警告视为错误吗？

Question

从长远来看，修复警告的短期烦恼是否可以带来红利？这样做通常可以避免哪些运行时错误？

Answer 1

我的观点是警告是有原因的，忽视它们会带来危险。虽然有些人真的很挑剔，但大多数情况下他们这样做是有充分理由的。我宁愿把它们修好并且编译得很干净。

Answer 2

这取决于你认为“你可以逃脱的警告”。此外，鉴于您将来的任何代码修改。

我想的时间越长，“我可以逃脱的警告”就越少。

Answer 3

我通常会修复所有警告，但不要将它们设置为错误......

Answer 4

一般，是的。

我确信有很多例外。第三方库标题不会以这种方式编译但你不想触摸是我能想到的最大的一个。 （即便如此，我有时会在#include行周围使用#pragmas来抑制某些标题中的警告，因此我可以在其余代码中保留警告错误。）

另一个例外是小项目;对我来说一个简单的经验法则是，如果我需要一个Makefile，那么它不再是一个小项目，我想得到关于警告，文档和单元测试的肛门。

Answer 5

这就是我认为您应该将警告视为错误的原因：

如果你有一长串的方法，其中某些东西可以出现null：

var amount = _client.SnatchLeftoverOrders( _username, _password, "pepperoni").Where( o => o.Ingredients.Any("mushrooms").Where( o => o.Ownersname.ToUpper == _incomingName ).Amount();

或类似的东西很多地方可能会发生空例外。

当你将这些行放在try / catch中而不是添加FirstOrDefaults（）然后分支为！null时，代码要简单得多。

如果你有一个catch，你必须对Exception对象做一些事情，否则就是错误（如果你把警告当作错误处理。

这不是赢得“精美编程”奖牌的方式，但它让事情变得简单。这些天编程中发生了太多的保姆事情。