Dead code, deactivated code, and the rest
The code your tests did not reach is the interesting part of the report. Four possible findings - and an evidence check that comes before any of them.
A coverage report has two halves. The covered part tells you what your tests did. The uncovered part tells you what you do not know - and that is the half an assessor reads first.
Terms such as dead code, deactivated code, defensive code and unreachable code have framework-specific meanings. The project glossary and applicable standard govern the disposition; a trace result can show non-observation, but it cannot determine the category or justification by itself.
Not observed is not unreachable. It means only that the code was not reconstructed within the valid observation scope of the stated runs.
Four findings structural coverage analysis can expose
First decide whether the item is validly observed and mapped. An unknown interval or unresolved mapping is not yet an uncovered source-code item. Only a valid uncovered item proceeds to the test-shortcoming, requirements-inadequacy, dead-code or deactivated-code disposition.
DO-178C section 6.4.4.3 asks you to resolve every gap in structural coverage. Structural coverage analysis can reveal four different project findings.
1. Shortcomings in the test cases or procedures
The code is reachable, it should have been exercised by the requirements-based tests, and it was not. Add or correct the tests and procedures, rerun, done.
This is the comfortable answer and, in a healthy project, the most common one. It is also the only one that does not require an argument.
2. Inadequacies in the software requirements
The uncovered code implements behavior that the requirements do not adequately specify - which can include unintended or unspecified function. Correct the requirements and propagate the change through implementation and verification. Classifying such a gap as a test problem hides exactly the finding that structural coverage analysis exists to surface.
3. Dead code
The code cannot be executed under any input. It is unreachable.
The expected resolution is removal, together with an analysis of how it got there. That last part is not punitive: unreachable code is often a symptom - a condition that can never be true, a defensive branch whose guard is already guaranteed upstream, a leftover from a requirement that changed. The code is a detail; the discrepancy it reveals may not be.
4. Deactivated code
The code is present in the binary but intentionally not executable in this configuration: a variant not used in this product line, a debug facility disabled in the release build, a feature switched off by configuration.
Deactivated code needs two things. First, evidence that its activation conditions are controlled in the delivered configuration - a claim about the whole system, not just the module. Second, a justification for its presence: usually reuse or a shared codebase, both legitimate, both worth stating.
Why the distinction is load-bearing
All four appear identically in a coverage report: as a gap. The report cannot tell you which one it is. Someone has to look.
That is why a tool’s handling of the residue matters more than its percentage. If unattributable machine code is silently dropped, the gap does not appear at all, and the question never gets asked. The report looks better and says less.
The compiler complicates this
Optimization can remove a source construct so that no corresponding object-code branch remains. Record that transformation separately from the coverage disposition - as supporting analysis, not as a fifth disposition.
The absence of an object-code branch does not itself prove that the source obligation is infeasible or verified. The project must disposition the source-level item using requirements-based testing, static or formal analysis, source-to-object analysis, or another project-approved method whose assumptions are stated. Use “proven infeasible” only when a reviewable analysis or proof supports that conclusion.
What good looks like
A coverage report that supports a certification argument shows, for every gap:
- where it is, at source and object level;
- which class it falls into;
- who decided that, and on what basis;
- for deactivated code, what prevents activation;
- for dead code, what the analysis found.
None of that is produced by a percentage. It is produced by a process, and the tool’s job is to make sure the process has all the gaps in front of it - not to tidy them away.
The practical advice
Do not treat the residue as a defect in the report. It is the part of the report with the most information per line.
Resolve gaps early and continuously. A campaign that leaves resolution to the end discovers dead code when changing it is most expensive.
Insist that unattributable code is visible. If your tool cannot show it, you cannot resolve it, and you will be asked about it anyway.
Sources
The definitions and the resolution obligation above come from:
- RTCA DO-178C / EUROCAE ED-12C, cited by section (licensed publication).
Take your most recent coverage report and walk its largest uncovered regions through the four findings above: each region should end with a named disposition or a named evidence problem. Every region that cannot is work you can still schedule yourself.
Related: what the standards require