Our website uses cookies to enhance your browsing experience.
Your message has been sent. We will email you at
If you haven't received our response, please do the following:
check your Spam/Junk folder and click the
"Not Spam" button for our message.
This way, you won't miss messages from our team in the future.
When analyzing larger projects static code analyzers usually generate a lot of error messages or warnings. And choosing whether all these errors should be fixed largely depends on current stage of project life cycle.
If project is being actively developed it makes a lot of sense to fix as many errors as possible - Quality Assurance did not yet spend time to detect these bugs. And when we are saving time we are actually reducing project cost.
When
But any static code analyzer always generates many so called "false-positive alarms" besides useful messages.
Various static analyzers treat this problem in different ways. Some analyzers ignore those suspicious fragments in code where the probability of an error is far from 100%. But most analyzers use an opposite approach, i.e. they generate much more "false alarms", however the risk that you might miss real error messages is much lower.
Since analysis results often contain a lot of such "false-positive" messages, there is no sense in correcting all the places in your code marked by the analyzer. However, developers must look through all the warnings anyway and configure the analyzer for each particular project eliminating such low-priority messages and focusing on detecting more serious issues.
0
0
0
0