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.
A coding standard that lives only in a PDF is a suggestion, though. A rule no build system checks is a rule that decays, one deadline at a time. I have read enough source code in litigation to recognize on sight what an unenforced standard looks like three years in.
BARR-C now has a free, MIT-licensed enforcement kit on GitHub. It converts the book's rules into build gates: a validated clang-format configuration, a clang-tidy mapping of every machine-checkable rule, compiler warning gates, a single-command check script, a CI job ready to drop in, and a coverage map that says rule by rule what the machine enforces and what still needs a person. The README opens on the question engineers actually type into a search box, how do I enforce the BARR-C coding standard, and answers it in five steps that carry a codebase from nothing to a gated CI build.
Enforcement was always the plan
Automated enforcement was never a bolt-on. 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 design was always that a machine should do the nagging about mechanical rules, leaving human reviewers free to spend their attention on design.
What changed is the toolchain. For years the machinery capable of checking these rules was commercial, and the analysis that mattered sat behind a license server. The equivalent machinery today, clang-format and clang-tidy, ships free inside the LLVM project and behaves identically on a laptop and in CI. The kit is that original intent rebuilt on tools every team already has. The standard now says as much where readers actually look: its own enforcement guidelines and the Embedded C Coding Standard home page both point straight at the kit.
What the machine checks
The coverage map is the document I would want put in front of me if I were judging somebody else's kit. Of the 167 rules in BARR-C:2018, 61 are gated, meaning at least one mechanism fails the build when they are violated. Two more are advisory, reported without breaking the build, because the book treats them as preferred practice rather than requirement. Four are automatable but not yet gated, and the map admits it. The remaining 100 belong to code review by their nature: comments, design intent, naming quality, hardware knowledge. A static analyzer sees the source code and nothing else, and whether a particular variable needs volatile is decided by the schematic and the datasheet, neither of which appears in the translation unit.
The map also handles overlap: where two tools check one rule, can they contradict each other? In every instance the stricter tool subsumes the looser one, and one compliant fix satisfies both. No pair demands what another forbids. That holds structurally, because the formatter never rewrites identifiers and never adds or deletes braces, so it cannot manufacture a static-analysis violation, and the kit's test suite proves it by formatting a file and then re-running every remaining gate.
Never trust an enforcement tool you have not watched fail
The test suite exists because two bugs taught us it had to, one in somebody else's tools and one in ours.
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 carried exactly this class of bug. A code generator quietly corrupted the regular expressions inside the check script's lexical gates, leaving them incapable of matching anything at all. The script ran, printed its cheerful output, and checked nothing. Writing the validation suite is what caught it: a set of tiny fixture files, each planting one violation, each asserted to make its gate fail. The dead gate failed that test on the very first run. The suite now runs in the repository's own CI on every change, alongside deliberate mutation checks, so a silently dead gate cannot ship again. If your team runs 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 further. A team whose CI ran the gates on every merge holds a machine-generated, timestamped record of engineering discipline. A team whose standard lived in a binder holds an aspiration. I have met both in the code rooms, and I know which one 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.
A growing share of the C landing in those codebases was never typed by a person. The kit ships two files aimed directly at that, a context file that makes the standard binding on AI code generators such as Claude Code, and a four-rule policy covering machine-generated code. That subject 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.