程序猿在做开发的时候是怎样对待warning的?直接忽视,详细研究,还是只是大体浏览一下?

Treat warnings as errors.用的编译器是公司自己的,对于绝大部分公司的产品,编译有warning是会失败的。
■网友
别人现成的库,只要不error就成。自己写的代码,一个warning都不能有。
■网友
鄙人不是真正的程序员,看到编译器警告的话基本如下操作看到编译器警告 就根据行数跳过去看看,如果是故意为了实现某些东西留下的就无视并且留下备注,写上为什么这样写 并且写好这里会出编译器警告。如果是自己不知道的警告 那么排查掉,实在无法排查的 依旧留下备注 等哪天有灵感以及时间的时候 再回来改。注: 适用于单人开发,如果是团队开发的话 不是自己负责部分的代码编译警告,最好找那段代码的负责人问清楚。
■网友
留着warning发布是极不负责任的行为.但,我就是这么任性的宝宝
■网友
做mfc安防的路过,目前负责编写一个超过十年的代码库。由于是跨平台的,而且由于前后人员编写的关系。 。。。。字符集。。。。嗯。。。宽窄字符总对不上。。。这是一个大坑,但据我所知目前还未发现与此相关的bug。。。。。我估计我们公司测试的水平比较水和业务操作比较单一有关系。。。 不光字符操作坑多,在一大堆warning里我目测并改掉的严重bug就有好几个,宏定义的函数接口用的参数个数错误,vs只报warning。。。。。毕竟国内搞安防的都是赚老实人的钱,技术需求真的不高。。。 我跟主管反应了warning太多潜在bug的问题,主管深思熟虑地说,字符的问题太多了,都改成_s的接口也没必要,屏蔽吧。。。。屏蔽吧。。。屏。。。蔽。。。。 我觉得很好啊(?▽?),然后有些实在难绕或者修改会造成代码冗余的我也在请示老大后选择了屏蔽。。。。比如sdk上的函数入口,cstr用到字符串参数上去,老的代码就是强转,自然出了warning,但这样的warning去改呢又没啥意义,代码行数还得加不少,修改点又多。还是轻松点disable warning#xxxx啦。 然后几百个warning就没了,好开森。 剩下几十个真的神坑的warning比如无用参数,引用错误,格式错误之类的确实不少。测试也测不出无用参数这种代码问题。前几代开发人员貌似都是懒得看警告的。要不是因为字符串ansi和unicode转来转去总是宽衣服窄衣服啥的,我也懒得去看警告。→_→
■网友
还是尽量弄清楚warning的原因,最好消灭掉!
■网友
视而不见,死机了,看看警告
■网友
完全我写的程序,warning都没有。但如果改别人的程序,或给别人程序加功能,就不管太多。


    推荐阅读