By Michael Barr
Note: This article offers practical commentary for attorneys and engineers. It is general commentary, not legal advice. Consult counsel about any specific matter.
In 2008 I wrote down a set of C coding rules because engineering teams kept arguing about the wrong things: a morning spent debating brace placement, and not one minute on the volatile keyword, which is the kind of omission that produces a field failure nobody can reproduce. The rules became the Embedded C Coding Standard, better known as BARR-C. It was substantially updated in 2018 and harmonized with MISRA C. Eighteen years on, the free PDF is still downloaded thousands of times a year from search results alone; engineers type "BARR-C" into Google as if it were a common noun, in ninety different phrasings, from more than 160 countries.
But a coding standard that lives only in a PDF is a suggestion. A rule nobody's build system checks is a rule that erodes, one deadline at a time. I have reviewed enough source code in litigation to know exactly what an unenforced standard looks like three years in.
BARR-C now has a free, MIT-licensed enforcement kit on GitHub. It turns the book's rules into build gates: a validated clang-format configuration, a clang-tidy mapping of the machine-checkable rules, compiler warning gates, a one-command check script, a ready-made CI job, and a coverage map that states, rule by rule, exactly what is enforced and what still needs a human. The repository's README opens with the question engineers type into a search box, how do I enforce the BARR-C coding standard, and answers it in five steps that take a codebase from nothing to a gated CI build.
Enforcement was always the plan
Automated enforcement is not a bolt-on idea. The standard itself asks that non-conforming code be caught primarily by automated scans, and commercial static-analysis vendors, LDRA among them, publish rule-by-rule compliance mappings for BARR-C:2018. The intent was always that a machine should nag about the mechanical rules so that human reviewers could spend their attention on design.
What changed is the toolchain. For years the machinery that could check these rules was commercial; the analysis that mattered lived behind a license server. Today the equivalent machinery, clang-format and clang-tidy, ships free inside the LLVM project and runs identically on a laptop and in CI. The kit is the original intent rebuilt on tools every team already has. And the standard now says so where readers actually look: its own enforcement guidelines and the Embedded C Coding Standard home page both point directly to the kit.
What the machine checks
The coverage map is the part I would want handed to me if I were evaluating someone else's kit. Of the 167 rules in BARR-C:2018, 61 are gated: at least one mechanism fails the build on a violation. Two more are advisory, reported without failing the build, because the book itself makes them preferred practices rather than requirements. Four are automatable but not yet gated, and the map says so. The remaining 100 are code-review territory by nature: comments, design intent, naming quality, hardware knowledge. A static analyzer sees only the source code, and whether a given variable needs volatile is settled by the schematic and the datasheet, neither of which appears in the translation unit.
The map also covers overlap: when two tools check the same rule, can they disagree? In every case the stricter tool subsumes the looser one and a single compliant fix satisfies both; no pair demands what another forbids. This holds structurally, because the formatter never rewrites identifiers and never inserts or removes braces, so it cannot manufacture a static-analysis violation, and the kit's test suite verifies it by formatting a file and then re-running every other gate.
Never trust an enforcement tool you have not watched fail
That test suite exists because of two bugs we found the hard way.
First: while assembling the clang-tidy mapping we verified every check against the LLVM documentation and source code, and found that three popular checks that look perfect for C, including the one that flags short and long and the one that flags goto, are quietly implemented as C++-only. They load without complaint on a C project and then never fire. A team could ship that configuration and believe, for years, that rules were being enforced which were checked exactly zero times. We excluded all three, documented why in the configuration itself, and replaced the lost coverage with lexical gates in the check script.
Second: our own first release had exactly this class of bug. A code generator subtly corrupted the regular expressions in the check script's lexical gates, in a way that made them incapable of ever matching anything. The script ran, printed its cheerful output, and checked nothing. What caught it was writing the validation suite: a set of tiny fixture files, each planting exactly one violation, each asserted to make its gate fail. The dead gate failed that test on the first run. The suite now runs in the repository's own CI on every change, alongside deliberate mutation checks, so a silently dead gate can never ship again. If your team has an enforcement config it has never watched fail, you do not know what it enforces.
Why a litigator should care
When firmware ends up in litigation, one of the first questions a source code review should answer is what standard the team committed to, because a coding standard adopted and dated before the dispute converts review from one engineer's opinion into measurement against a benchmark the company itself selected.
An enforced standard sharpens that evidence. A team whose CI ran the gates on every merge has a machine-generated, timestamped record of engineering discipline. A team whose standard lived in a binder has an aspiration. I have seen versions of both in the code rooms, and I know which team I would rather defend.
The repository is also the feedback channel
The GitHub repository hosts the errata for the 2018 edition, something the printed editions never had, and an issue filed there reaches the people who maintain the standard. A larger update to the standard is in the works, and the kit is how its improvements will reach real codebases fastest.
An increasing share of the C being committed to those codebases was not typed by a person. The kit includes two files aimed squarely at that fact, a context file that makes the standard binding on AI code generators such as Claude Code, and a four-rule policy for machine-generated code. That story deserves its own article, and it gets one here next month.
BARR-C:2018 is free, the kit is free, and the two now enforce each other: the book explains why each rule exists, and the kit makes forgetting them impossible.
Barr Group's team of electronics and software expert witnesses provide experienced and unbiased source code reviews, expert reports and testimony for product liability, patent infringement, software copyright, and trade secrets litigation involving computer-based technology and software. HIRE AN EXPERT
Get a matched recommendation >
Free, confidential, conflicts-checked, and our fee is built into the expert's hourly rate, so we are paid only if you retain.