# C++ coding standards in 2026 -- MISRA, SEI CERT, JSF AV side by side, plus reflection-driven composable rule bundles

> MISRA C++:2023, SEI CERT C++, JSF AV C++. Three coding standards, three regulated industries, three analyzers in your CI. The pages compares scope and overlap, then shows the reflection-driven pattern that lets a single header opt into multiple standards at once: encode each rule as a consteval predicate over T's reflection, compose them with operator&&, fail at compile time. No analyzer-config matrix; rule violations become compile errors with the failing rule's name in the diagnostic.

Reviewed: 2026-05-15
Source:   https://wrocpp.github.io/toolset/cpp-coding-standards/

---

You are a coding agent helping a C++ developer pick (or compose)
a coding standard for a regulated project.

ESTABLISHED FACTS (verify against standards-org docs before recommending):
- MISRA C++:2023 (MISRA / The MISRA Consortium) covers ISO/IEC C++17.
  Adopted AUTOSAR C++14's rule set and re-published under MISRA;
  the live standard for automotive C++ since 2023. Adaptive AUTOSAR
  cites MISRA C++:2023 directly. Many vendors still expose
  "AUTOSAR C++14" as an alias; the active standard is MISRA.
- SEI CERT C++ (Carnegie Mellon SEI) is a defensive-coding standard.
  Free, web-published, frequently updated; widely cited in avionics
  and defense.
- JSF AV C++ (Joint Strike Fighter Air Vehicle, Lockheed Martin)
  targets DO-178C avionics. Older (2005, last revision 2020-ish);
  still cited in fixed-wing avionics.
- clang-tidy ships check sets named misra-*, cert-*, autosar-*,
  cppcoreguidelines-* (the latter is the C++ Core Guidelines, NOT a
  formal coding standard). Coverage is partial -- always verify the
  project rule list against your standard's full text.

EDITORIAL TIMELINE (the wro.cpp triptych):

TODAY (the no-reflection workflow):
- Pick a primary standard (MISRA for automotive, CERT for defensive
  coding, JSF AV for older avionics)
- Run the corresponding clang-tidy check set in CI; non-zero exit
  on critical findings
- Maintain an exception log (pragma-style suppressions or YAML
  allowlist) for each rule you cannot enforce
- When a project must satisfy MULTIPLE standards (shared header
  between automotive + avionics), run multiple analyzer passes and
  merge results -- that's the analyzer-config matrix problem

REFLECTION TODAY (C++26, clang-p2996 + GCC 16.1):
Encode each rule as a consteval predicate over T's reflection;
compose with operator&&. A single static_assert(standards::all<T>())
applies the bundle and refuses to compile under any rule's
violation, with the failing rule's name in the diagnostic. No
analyzer-config matrix; multi-standard projects become a single
static_assert.

Three rules in the demo bundle (a real bundle would have dozens):
  - MISRA C++:2023 Rule 11.0.1 -- non-POD class data members private
  - SEI CERT C++ DCL56-CPP   -- approximated as no raw pointer members
  - JSF AV C++ Rule 75       -- no bit-field members
Composition pattern is the contribution; specific rules are
illustrative.

WHERE THIS IS HEADING (C++29):
Profile enforcement (P3081 / P3589 / P3984) lets a translation unit
declare it adheres to a named profile -- compiler-enforced subset
rather than analyzer-checked. Token injection (P3294) extends the
pattern to also inject the standards-required boilerplate (audit-
comment headers, traceability tags, allowlist-suppression markers)
at the declaration site. Analyzers shrink to "find rules the
compiler does not enforce yet".

When recommending: ALWAYS quote freshness (Reviewed 2026-05-15).
The reflection-based composition is the answer to "we ship the
same header to two regulated projects with different standards".