Static analysis is not only about directly finding bugs, but also about finding bug-prone situations that can decrease code understanding and maintainability. Static analysis can handle many other properties of the code:
- Code metrics: for example, methods with too many loops, if, else, switch, case… end up being non-understandable, hence non-maintainable. Counting these through the code metric Cyclomatic Complexity is a great way to assess when a method becomes too complex.
- Dependencies: if the classes of your program are entangled, effects of any changes in the code becomes unpredictable. Static analysis can help to assess when classes and components are entangled.
- Immutability: types that are used concurrently by several threads should be immutable, else you’ll have to protect state read/write access with complex lock strategies that will end up being un-maintainable. Static analysis can make sure that some classes remain immutable.
- Dead code: dead code is code that can be removed safely, because it is not invoked anymore at runtime. Not only can it be removed, but it must be removed, because this extra code add unnecessary complexity to the program. Static analysis can find most of dead code in your program (yet not all).
- API breaking change: if you present an API to your client, it is very easy to remove a public member without noticing and thus, breaking your clients code. Static analysis can compare two states of a program and can warn about this pitfall.
- API usage: some APIs are intended to be used carefully. For example, a class that hold disposable fields must be itself disposable in general, except when the disposable field lifetime is not aligned with the class instances lifetime, which then sounds like a design problem.
Many interesting tools exist to detect bugs in your C++ code base like cppcheck, Clang and visual studio analyzer. But what about the detection of the bug-prone situations?
If the static analysis tools creators could decide which situations are considered as bugs, it’s not the case of the bug-prone situations which depends on the development team choices. For example a team could consider that a method with more than 20 lines is c0mplex, another team could define the max to 30. If a tool provides the detection of some bug-prone situations, it must provides also the possibility to customize it.
Code as Data is the better way to detect the Bug-prone situations
Static analysis is the idea of analyzing source code for various properties and reporting on those properties, but it’s also, philosophically, the idea of treating code as data. This is deeply weird to us as application developers, since we’re very much used to thinking of source code as instructions, procedures, and algorithms. But it’s also deeply powerful.
After the source code analysis of a source file, we can extract its AST and generate a model containg many interesting infos about the code. This way we can query it using a code query language similar to SQL.
CppDepend provides a powerful code query language named CQLinq to query the code base like a database. Developers, designers and architects could define their custom queries to find easily the bug-prone situations.
With CQlinq we can combine the data from teh code metrics, dependencies, api usage and other model infos to define very advanced queries that match some bug-prone situations.
Here’s an example of a CQLinq query that matches the most complex methods:
Summary
It’s better to combine many C++ tools to detect some problems in your C++ code base, some tools detect bugs, some others detect also the bug-prone situations .With CppDepend we try to combine between many tools, indeed we provides an easy way to define your queries, but also we added recently the feature to import the result from other static analysis tools to query them with CQLinq.