Use Static Analysis to guard correctness and consistency

Static Analysis is the automated process of analyzing source code without executing it, to identify vulnerabilities, defects, code smells and coding standard violations.

In simple terms, it is like a grammar checker for source code.

Shift Left on Quality

Static analysis enables developers to shift left on the detection of quality issues. This is possible because these tools tend to be fast and can be executed early in the development process, allowing developers to catch and fix issues while it is still very cheap to do so.

Four Stages of Static Analysis

Static analysis is typically triggered during the following stages of the development cycle:

Live while coding in an IDE
- Immediate feedback can be presented in the IDE via IDE extensions running in the background.
During the build process
- The compiler enforces rules by producing warnings and errors when violations are detected during compilation.
  - cppbestpractices (Jason Turner): Use the Tools Available: Compilers
- Addition tools may be configured to execute during the build process.
At git commit using a git pre-commit hook
- To provide feedback on the staged changes, and prevent them from being committed.
In a CI/CD pipeline
- To safeguard the trunk from being polluted with rule violations.

Static Analysis is low cost and delivers high value

Fast: Often runs in seconds, without requiring a build or testing environment, it is faster and cheaper than manual code review.
Finds issues early: When they are still cheap to fix.
Automated and Deterministic: The tools are consistent and repeatable, where manual code review has a risk of human oversight.
Enforces knowledge sharing: Feedback from static analysis teaches developers about rules and best practices at the time when it most relevant. No need to learn pages of documentation up front. Knowledge is delivered just-in-time.
Scales across teams and time: Knowledge documented as automated checks can easily reach across multiple teams and repositories. By building static analysis into the process, lessons learned from past mistakes can even reach new hires in the future who were not present when such mistake was made the first time. This is in stark contrast to knowledge sharing by email or powerpoint session: This transfers knowledge to a fixed audience at a snapshot in time, at risk of being forgotten.

Not running an extensive set of static analysis as part of the development process is simply unprofessional.

Refocusing The Code Review

Guidelines & Principles

It’s valuable to build a mindset of proactive automation.

Think proactively

Every issue you encounter is a chance to improve the system, not just the code.

Next time you hit an issue, ask yourself: “Could this have been prevented with a static check?” or consider “I wish someone had told me that …”.

Raise the idea. Brainstorm it, build it, or at least share it with colleagues. Maybe it could have been prevented with an existing tool. Maybe you’ll have to roll your own script. Either way, think: How could this be prevented?

Take warnings seriously

Warnings are not meant to be noise. Fix the issue, report or patch false positives, or disable the specific check. Just don’t let them accumulate.

Warnings that accumulate lose value. If you have 500 warning messages:

Valuable feedback can get lost in the noise
Dealing with it becomes a daunting task.
Broken Window Theory: Allowing warnings to exist, encourages toleration of new warnings to be introduced.

Strict by default, relax when justified

Strict by default

Start with the most rigorous settings for your CI pipelines and static analysis tools. Enable all recommended warnings, checks, and error reporting. Treat violations as build failures by default.

Review your setup

Are you benefiting from static analysis?
Do you get live feedback in your IDE?
Are your tools and configurations up to date?
Are your tools still running correctly or failing silently?