|
Yes, here you are, you knights of code, fighting for the holy grail.
In real life we got to continue an existing project last year.
There were more than 70.000 warnings, not to mention about the same number of messages, part of them critical (!) of the static code analysis.
So, at least, they don't lie in the poll. Thank you.
|
|
|
|
|
Depends what you are working on but that wasn't an answer in the survey 
Leaving aside the quirks of C++ compilers (which I try never to touch) you should assess every warning and either fix it or handle it. Handling it doesn't mean ignoring it, it means handling it properly. This is however a general rule and if your code works with 70000 warnings it might be more sensible leaving them in so you are reminded to revisit them on a wet day without much else on and find out why.
|
|
|
|
|
You are absolutely right.
Warnings are useful to help you create better code - and I always try to understand the reason and to fix it properly.
But I have seen so many old, grown projects, with big lists of warnings, so I would never expect option 1 on position one.
|
|
|
|
|
I once fixed around 300 warnings in a code base that I inherited. It turned out to be the wrong approach because it broke the code. I did not have the time to figure out why so, I just said <blank it=""> an ignored them.
To this day I still wish I had had the time to find why fixing the code broke the code. 
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
Hau to fix wanrings in code, urgentzz please.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
If you have to support multiple C++ compilers, option 1 is virtually impossible to achieve. Option 2 is much more realistic.
|
|
|
|
|
I'm relieved, since that's the one I picked. Our preference is for warning-free code. In some circumstances the warnings are suppressed via #pragma, but that means we deliberately made a choice about the issue.
I would have chosen the "analyzers" option, but we're mostly stuck with VS2008 which doesn't include much in the way of code analysis tools.
Software Zen: delete this;
|
|
|
|
|
#realJSOP wrote: I honestly expected option 1 to be the clear leader.
As did I. That's scary, because some warnings, like = vs. == are critical to pay attention to.
Latest Article - A 4-Stack rPI Cluster with WiFi-Ethernet Bridging
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Likewise, within a few months of starting professional C (and later C++) coding I'd learned to my cost that ignoring warnings (and also not paying close attention to PC-Lint output) was stupid if you wanted to be productive and avoid "howler" bugs later.
|
|
|
|
|
Yup - warnings are harbingers of doom.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
A warning is there for a good reason.
Our build server compiles with the setting "treat warnings as errors".
Write clean code and do not work in a "oh it's just a warning, but still compiles. That's ok for me" manner.
We run code analysis by the microsoft rules, we run sonar qube, we have several other tools in place that even track whether files are tab- oder blank-formatted.
Quality of the files has priority#1 from the dev perspective. Every dev has to be able to open the file in the exact same layout as every other developer in the team.
we have coding guidelines in place, we even work through the info-messages that tell naming convention conflicts.
in the long run, this saves lots of time.
If you write your files clean from the beginning, this is not a noticable overhead.
|
|
|
|
|
This used to drive me mad - I once inherited a code base with 1000+ warnings (actually more like 5000 but vb.net won't generate more than 100 per project) and although 99% of them were harmless there were several genuine warnings that were buried among the mess. Spent hours smiting them all to get a clean build happening.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
