|
Having used Coverity code analyser in work, writing stock exchange software, I would like to point out it is often pedantic and other times annoying.
* It is well known for a high percentage of false positives - code that triggers rules which on investigation do not, in fact, violate the rule.
* Coding style causing rule violations - when a deliberate, known entity in the code causes an inappropriate rule violation. "Missing break statement" is a classic. Switch statements are occasionally MEANT to have missing break statements, the whole point is that some conditional flows are inherently sequential and 'should' trigger more than one block, but there are alternatives so someone invented this static code analysis rule. It remains controversial, but it not "unsafe" code.
* Complex matrixes are used AS A GUIDE, a statistic. Nothing more. It IS true if you have a high complexity that to fully test every code path requires an equally (and often unrealistically) high number of tests. In reality however a vast amount of complexity from these statistic comes from the defensive paths on param and return type checks. A function that takes 3 parameters and calls 4 methods already gets a complexity minimum of 22 before it doesn't anything else. Breaking up code even further reduces the individual functional complexity, but moves it into the harder (impossible?) to measure integration complexity of class hierarchies, polymorphism, indirection and design patterns.
Thus architectural/integration/design complexities usually cost memory and speed. Not something you have lots to play with in embedded real time systems.
One thing not mentioned is the scope of the analysis. If you include build time code, test code, un-used code modules you will usually receive much higher rule violations as you are analysing code that nobody really cares about the ultimate quality of. It is code that is used during development, if it fails, it's obvious and the impacts negligible.
However. I write critical business systems. The costs of failures are complex analysis to work out what happened, restore the data to a sensible state, work out which transactions to anull, revoke and move on. It costs money and time.
In embedded control systems used in real world, real time critical operations, I would expect a much higher standard. Failure here costs lives.
__________________
Trunk = Boot | Hood = Bonnet | Sidewalk = Pavement | Transmission = Gearbox | Stick/shifter = Gear knob/stick | E-brake = handbrake | Windshield = Windscreen | Turn signal = Indicator
|