C++ Core Guidelines: version numbers in the text, and a site that lags master

One markdown file, kept in ASCII so machines can post-process it

The guidelines are a single file, CppCoreGuidelines.md, written in GH-flavored Markdown. The editors keep it simple and mostly in ASCII on purpose, so that automatic post-processing such as language translation and reformatting can be applied to it.

That constraint shapes everything around the document. A rule that needed a diagram or a table of wide characters would break the pipeline, so the prose carries the argument instead. The repository still holds PNG assets, including two named for parameter passing and one for the guidelines logo, which is the tell that figures exist for the published site even though the text does not depend on them. A translator or a reformatting script that handles only the text loses those images.

It also explains the shape of the repository. Alongside the document there are _config.yml, _includes/, _layouts/, params.json, public/, scripts/, docs/, talks/ and index.html, which is a generated site rather than a plain markdown file, and GitHub reports the repository's primary language as CSS for exactly that reason. Nothing in the tree is a C++ library; the deliverable is prose.

The document is meant to be copied. The README states that the guidelines can be freely copied and modified to meet your organization's needs, and it opens with a line from Bjarne Stroustrup: within C++ is a smaller, simpler, safer language struggling to get out.

The website is integrated by hand and can be older than master

There are two copies of the guidelines and they are not the same copy. The master branch holds the document; the editors maintain one version formatted for browsing at the isocpp homepage, and the README is explicit that this version is manually integrated and can be slightly older than the version in the master branch.

That is a small sentence with a real consequence. If you read the website and your colleague reads master, a rule may have changed without either of you noticing, and the usual workflow of pinning a version does not apply here because there are no releases to pin. Rule links that point at the published site are the ones most likely to be stale.

The manual integration is also why the site build is a separate concern from the document. Changes to the Jekyll scaffolding in _config.yml, _includes/ and _layouts/ are made by the editors and then integrated, so a fork that renders the markdown itself will not inherit their fixes, and a fork that copies the whole site inherits the delay.

The pragmatic rule for anyone citing a rule in a design document: cite the section, and check it against master rather than against the page you happened to read.

The version number is in the introduction, and the newest tag is from 2017

There is no strict release cadence, and the README says so directly. The guidelines are a constantly evolving document, and Bjarne Stroustrup periodically reviews it and increments the version number in the introduction; the check-ins that increment the version are the ones tagged in git.

Look at those tags. The most recent is v0.8, whose text reads Update to version 0.8, 19 Jun 2017, and before it v0.7 dated Aug 24, 2016 and v0.6 dated Sep 14, 2015. Two of the three carry a git timestamp of 2017-04-04, which means the tag dates are not the version dates and you cannot sort the history by tag date to find the newest guidance.

The repository is not archived, and its last push was on 2026-08-06, so the text is still being edited, years after the last version increment. That combination is the practical takeaway: the document moves continuously while its version number moves rarely. If you need to know whether a rule changed, read the diff; if you need to state which version your team adopted, the number in the introduction is the only identifier the project offers, and it will not tell you how recent that text is.

Modern C++ means C++11 and newer, and naming is explicitly out of scope

The scope question is answered by the README's own framing. The aim is to help people use modern C++ effectively, and by modern C++ they mean C++11 and newer, posed as what you would like your code to look like in five years, or ten, given that you can start now.

The focus is on higher-level issues: interfaces, resource management, memory management and concurrency. The claim attached to those is specific, that following the rules leads to code that is statically type-safe, has no resource leaks, and catches more programming logic errors than is common today, and that it will still run fast.

What is deliberately excluded is as useful as what is included. The editors are less concerned with low-level issues such as naming conventions and indentation style, while also saying that no topic that can help a programmer is out of bounds. The consequence for a team is that the guidelines are not a replacement for a style guide, and a lint configuration derived from them will be silent about naming. Add that layer from your own conventions.

One more admission worth reading: the initial set of rules emphasises safety and simplicity, may very well be too strict, and the editors expect to introduce more exceptions as real-world needs arrive. Expect to argue for exceptions rather than to treat every rule as settled.

Rules are written to be cited by an analyser the project does not ship

The intended adoption path is a tool, not a habit. The rules are designed to be supported by an analysis tool, and violations will be flagged with references or links to the relevant rule. The README also says explicitly that nobody is expected to memorise the rules before writing code, which only makes sense if a machine is doing the flagging.

Here is the gap. The README names no specific analyser and no configuration file, and the repository's top-level entries contain no analysis configuration: what is there is .travis.yml, .github/, scripts/, docs/ and the site scaffolding. The document defines the targets and leaves the enforcement to whoever brings the tool.

The second gap is the same one, one level up. The rules are meant for gradual introduction into a code base, and the project says it plans to build tools for that and hopes others will too. So there is no official path for adopting these rules in a large existing codebase; you choose the subset you want enforced, enable it, and fix what it finds.

Written that way, the rules are usable references rather than a migration. A team that wants both has to build the second half itself.

Many rules assume the Guidelines Support Library, a dependency you take on faith

The guidelines are not only prose. Many of them make use of the header-only Guidelines Support Library, and the README points to one implementation hosted by Microsoft at the GSL repository.

That single sentence is the whole dependency story, and it has edges. Following the rules can add a second library to your build, versioned on its own schedule rather than with the document, and the README names one implementation without listing the alternatives, so a team that already vendors a different one has no guidance from this page on whether it satisfies the rules.

The header-only part is the friendly detail. There is nothing to link against, so adopting the support types is a source dependency rather than a build-system change, which is why a text-first document can lean on it.

If your interest is the reasoning rather than the types, the rules stand on their own as prose, since the library is what implements several of them, not what defines them. Decide which of the two you are taking before you add a dependency, because once the code uses the support types, removing the library later is a rewrite rather than a version bump.

Copying the text is sanctioned, and LICENSE is still the authority

The project invites modification. Comments and suggestions are welcome, the plan is to modify and extend the document as understanding and the available libraries improve, and the guidelines can be freely copied and changed to suit an organisation. CONTRIBUTING.md holds the details, SECURITY.md sits beside it, and the Standard C++ Foundation website that hosts the rendered guidelines is credited to DigitalOcean.

One detail to check before you republish anything. The repository's licence field carries no asserted identifier, and the licence terms live in the LICENSE file at the root. The README's sentence about copying and modifying is a statement of intent, and the file is the grant. If you are vendoring the text into an internal wiki, a linter configuration or a printed standard, read the LICENSE file rather than relying on the summary.

The same caution applies to the version number. Since it is incremented by hand in the introduction and the newest tag is v0.8 from 2017, an internal copy should record the commit it came from alongside the version it claims, or your forked text and the upstream text will diverge without a marker.

The rules are designed to be freely adopted, and the mechanics of adopting them are where the work is: pick the subset, find the analyser, read the licence.

Editorial conclusion

Adopt the C++ Core Guidelines if you want a shared, citable rule set for interfaces, ownership and concurrency, and if you are willing to enforce it with a static analyser rather than by convention. Do not adopt them as a style guide, since the document says it is less concerned with naming conventions and indentation, and do not expect a migration tool, because gradual introduction is stated as something the project plans to build. Verify first which copy you are reading: master, or the browsable site, which is integrated by hand and can be slightly older than the master branch.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes