消除编译器警告是个好主意吗? [英] Is it a good idea to eliminate compiler warnings?
问题描述
过去，我曾使用-Wall和gcc的其他开关来消除涉及到的项目的所有编译器警告.类似地，在Perl中，我始终使用严格警告和使用警告进行编程(并且经常- T也是如此)，以尝试达到我所能达到的最佳代码质量.我了解到几年前，Perl搬运工小组努力使perl本身(Perl解释器)在gcc下启用所有警告的情况下干净地编译.显然，他们认为这对于代码质量而言是个好主意.我也了解到，如今，Perl程序员使用Perl :: Critic在其代码中添加了更多警告，当它们违反Damian Conway的Perl Best Practices一书中的最佳实践时，会向他们发出警告(我相信还有其他来源).
我一直对以这种方式清理过的代码有很好的感觉，但是有时候我无法避免有些工作被浪费掉的感觉.例如，在十年前的Intro C类中，有人教我如何像下面这样启动main()函数:
void main(void) {
这是最小的，只能在不返回值且不访问参数时使用.在这种情况下，它可以正常工作，但是gcc警告会告诉您该功能确实应该像这样:
int main(int args, char* argv) {
我必须回溯过去输入过几百个未使用的int args，char * argv行.是我真的使我的代码变得更好，还是只是手指短了些?
如今，我正在Eclipse中用Java编程，我们的项目有成千上万的警告.我想清理它们.其中有些特别难以理解和消除，但我正在慢慢学习.其中一些我不得不使用编译器指令来抑制警告(通常以极小的最小方法来排除忽略警告的不良习惯)，但是我也在寻找处理这些警告的方法.
这值得一个程序员的时间吗?如果您跟踪每个编译器警告，一个项目真的会更好吗?
如果没有其他事情，将警告的数量减少到零似乎很不错，这样就不会在混乱中丢失严重的警告.
注意:解决方案
是的，当然可以.警告表示您的代码中可能存在错误.要么修复它，要么应该禁用警告-如果您不打算对其采取行动，则收到警告只是阻止您检测何时出现新的警告.
获取和保持代码无警告的最简单方法就是始终使用-Werror(在Visual Studio中为/WX)或同等版本进行编译.
In the past I've worked with -Wall and other switches for gcc to eliminate every compiler warning for projects I've been involved in. Similarly, in Perl, I always program with use strict and use warnings (and often -T as well) to try to achieve the best code quality I can. I understand that a few years ago, the Perl porters group worked hard to make perl itself (the Perl interpreter) compile cleanly under gcc with all warnings enabled. Obviously they felt that was a good idea for code quality. I also understand that nowadays Perl programmers have been adding even more warnings to their code with Perl::Critic, which warns them when they violate best practices found in Damian Conway's Perl Best Practices book (and from other sources, I believe).
I always had a good feeling about code that I had cleaned up this way, but sometimes I couldn't avoid the feeling that some of the work was a little wasted. For example, in my intro C classes over a decade ago, I was taught to start my main() function like this:
void main(void) {
This was minimal and could only be used when you weren't returning a value and weren't accessing your arguments. It works just fine in that case, but gcc warnings would let you know that this function really ought to look like:
int main(int args, char* argv) {
I must've typed a couple of hundred unused int args, char* argv lines back in the day. Did I really make my code better, or just wear my fingers down shorter?
Nowadays I'm programming in Java in Eclipse, and our project has tens of thousands of warnings. I'd like to clean them up. Some of them are especially difficult to understand and eliminate, but slowly I'm learning. A few of these I've had to handle with compiler directives to suppress warnings (usually in tiny minimal methods to factor out the bad practice of ignoring warnings), but I'm finding ways to handle those, as well.
Is this worth a programmer's time? Will a project really be much better if you track down every single compiler warning?
If nothing else, it seems like it'd be nice to reduce the number of warnings to zero so that serious warnings wouldn't get lost in the mess.
Note: Duplicate of this question
Yes, definitely. A warning is an indication that something may be wrong in your code. Either you fix it, or you should disable the warning -- if you're not going to act on it, having the warning is just preventing you from detecting when new warnings appear.
Easiest way to get and keep the code warning-free is simply to always compile with -Werror (/WX in Visual Studio) or equivalent.
这篇关于消除编译器警告是个好主意吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
