isocpp
CppCoreGuidelines
CSS2015–2026
isocpp / CppCoreGuidelines
CppCoreGuidelines
The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++
85Distinct people
100Mentions
1Explicit recommenders
45.5KGitHub stars
What to know before exploring
What it is
The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
Once you've become familiar with the basics of the language, I highly recommend taking a look at C++ Core Guidelines https://github.com/isocpp/CppCoreGuidelines
filereaper used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- microsoft/gsl · linked in 3 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:56:56 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year100 dated mentions
Observed mentions: 2015-09-16 08:12:12 UTC to 2026-01-26 15:51:17 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 21 | 11 | 10 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 20 | 2 | 18 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 12 | 0 | 12 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 16 | 3 | 13 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 1 | 0 |
From the project README
An excerpt from the repository, fetched Nov 12, 2026.
Read the project’s introduction
"Within C++ is a smaller, simpler, safer language struggling to get out."
-- Bjarne Stroustrup
The C++ Core Guidelines are a collaborative effort led by Bjarne Stroustrup, much like the C++ language itself. They are the result of many
person-years of discussion and design across a number of organizations. Their design encourages general applicability and broad adoption but
they can be freely copied and modified to meet your organization's needs.
Getting started
The guidelines themselves are found at CppCoreGuidelines. The document is in GH-flavored MarkDown. It is intentionally kept simple, mostly in ASCII, to allow automatic post-processing such as language translation and reformatting. The editors maintain one
version formatted for browsing. Note that it is manually integrated and can be slightly older than the version in the master branch.
The Guidelines are a constantly evolving document without a strict "release" cadence. Bjarne Stroustrup periodically reviews the document and increments the version number in the introduction. Checkins that increment the version number are tagged in git.
Many of the guidelines make use of the header-only Guidelines Support Library. One implementation is available at GSL: Guidelines Support Library.
Background and scope
The aim of the guidelines is to help people to use modern C++ effectively. By "modern C++" we mean C++11 and newer. In other
words, what would you like your code to look like in 5 years' time, given that you can start now? In 10 years' time?
The guidelines are focused on relatively higher-level issues, such as interfaces, resource management, memory management, and concurrency. Such
rules affect application architecture and library design. Following the rules will lead to code that is statically type-safe, has no resource
leaks, and catches many more programming logic errors than is common in code today. And it will run fast -- you can afford to do things right.
We are less concerned with low-level issues, such as naming conventions and indentation style. However, no topic that can help a programmer is
out of bounds.
Our initial set of rules emphasizes safety (of various forms) and simplicity. They may very well be too strict. We expect to have to introduce
more exceptions to better accommodate real-world needs. We also need more rules.
You will find some of the rules contrary to your expectations or even contrary to your experience. If we haven't suggested that you change your
coding style in any way, we have failed! Please try to verify or disprove rules! In particular, we'd really like to have some of our rules
backed up with measurements or better examples.
You will find some of the rules obvious or even trivial. Please remember that one purpose of a guideline is to help someone who is less
experienced or coming from a different background or language to get up to speed.
The rules are designed to be supported by an analysis tool. Violations of rules will be flagged with references (or links) to the relevant rule.
We do not expect you to memorize all the rules before trying to write code.
The rules are meant for gradual introduction into a code base. We plan to build tools for that and hope others will too.
Contributions and LICENSE
Comments and suggestions for improvements are most welcome. We plan to modify and extend this document as our understanding improves and the
language and the set of available libraries improve. More details are found at CONTRIBUTING and LICENSE.
Thanks to DigitalOcean for hosting the Standard C++ Foundation website.
Read the full README on GitHubWhat Hacker News says
100 sourcesA writable file closing itself when it goes out of scope is usually not great, since errors can occur when closing the file, especially when using networked file systems.
https://github.com/isocpp/CppCoreGuidelines/issues/2203
In C++ says “We have try... finally at home”If that is what profiles were actually doing, it would probably make sense. But it's not what profiles are doing.
Instead, for example, the lifetime safety profile (https://github.com/isocpp/CppCoreGuidelines/blob/master/docs...) is a Rust-like compile time borrow checker that relies on annotations like [[clang::lifetimebound]], yet they also repeatedly insist that profiles will not require this kind of annotation (see the papers linked from https://www.circle-lang.org/draft-profiles.html#abstract).
Their messaging is just not consistent with the concrete proposals they have described, let alone actually implemented.
In Safe C++ proposal is not being continuedI liked "Effective Modern C++" although it is somewhat out of date by now. Stroustrup's recent article "21st century C++" https://cacm.acm.org/blogcacm/21st-century-c/ gives an overview (but not details) of more recent changes. There are also the C++ core guidelines though maybe those are also out of date? https://github.com/isocpp/CppCoreGuidelines
I've been looking at Rust and it's a big improvement over C, but it still strikes me as a work in progress, and its attitude is less paranoid than that of Ada. I'd at least like to see options to crank up the paranoia level. Maybe Ada itself will keep adapting too. Ada is clunky, but it is way more mature than Rust.
In A tail calling interpreter for Python (already landed in CPython)> close a file (which ironically is the poster child for RAII)
Yes, I call this "RAII is a lie" (T-shirt pending).
Closing file descriptors is univerally used to showcase RAII, but it should never be used for that.
C++ has the same problem:
https://github.com/isocpp/CppCoreGuidelines/issues/2203
In there, it is acknowledged that a manual Close() should always be provided, and used if you want guarantees.
> is a bad pattern
Good that Rust at least figured it out early that it's a bad pattern!
Never use RAII in situations where the cleanup can fail!
In Don't defer Close() on writable files (2017)If you aren't aware of the c++ core guidelines[1] - it should be on your radar.
Also, it might not be a popular opinion, but I think Bjarne's books are just fine.
A Tour of C++ (3rd edition) [2]
Principles and Practice Using C++ (3rd Edition) was just published in april 2023 [3]
[1] https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
[2] https://www.stroustrup.com/tour3.html
[3] https://www.stroustrup.com/programming.html
In Are We Modules Yet?I admit I mostly don’t understand the “modern C++ is safe” argument. I maintain a decent size C++ code base, I try to use modern features in good taste, and I do think that C++ has added a lot of nice things. But nice != safe.
basic_string_view is new in C++17. It sure beats pointers, but it’s a far cry from the kind of safety that you get in essentially any other language (except C): it is a reference with unknown lifetime, and the toolchain does not help track that lifetime.
I think that Stroustrup would say that the C++ Core Guidelines fix this, and I think he’s referring to this:
https://github.com/isocpp/CppCoreGuidelines/blob/master/docs...
which seems like it’s maybe partly implemented in some version of Visual Studio and was maybe prototyped in clang. But it does not seem to be a well-specified language or a fully-implemented la
Read the rest
nguage, and I can’t use it now.
So, as far as I’m concerned, I can use Rust or Python or Perl or Go or Swift or bash or Java or JavaScript or Haskell or Lisp or Scheme or O’Caml or Tcl and I can manipulate strings without worrying about undefined behavior. Or I can use C++ and worry. Or I can dream about using “Modern C++?”
> Quite good reading to stay up to date how to write proper C++ code instead of classical C with C++ compiler,
This is good too: https://github.com/isocpp/CppCoreGuidelines
I also liked Scott Meyer's book "Effective Modern C++".
In A Tour of C++ (Third edition)The argument against unsigned is that people abuses unsigned as a way of false safety, as a form of assert. They think the number cannot go below zero or above maxvalue. But in practice it can under- and overflow, so this is a bogus assert. I think there is a valid point in this.
So, if someone does x=(0-1), signed will contain (-1) and unsigned will contain (MAXVALUE) (255 if x is char, 8 bits). The point being that (-1) is clearly wrong and invalid, and 255 is valid but wrong. The price to pay for this is one bit of reduced range (meaning, reducing the range by half).
Now, all modern processors have under- and overflow checks. It is also true that nobody uses them regularly, and that they are not easily accessible in C.
Therefore: use unsigned only for modulo arithmetic. For the rest, used signed numbers, as they behave like you would e
Read the rest
xpect.
Also, the C++ Core Guidelines:
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
That's great to hear! I'm sure I could find it, but are the libreoffice coding standards written down (and could you send them my way)?
On the topic of coding standards, there's an excellent github repo https://github.com/isocpp/CppCoreGuidelines which even quotes Bjarne Stroustrup as saying "Within C++ is a smaller, simpler, safer language struggling to get out." There are hundreds of recommendations, like 'ES.31: Don't use macros for constants or "functions"'.
In Show HN: Modifying Clang for a Safer, More Explicit C++Ah yes, the one that still just wraps a raw pointer in the end
https://github.com/isocpp/CppCoreGuidelines/issues/1038
In Experimenting with Rust in ChromiumYou gloss over the complexity cost of having too many overlapping tools in the bag though, a complexity cost that has drowned projects in the past. Arguably C++ as a language could be improved if someone was able to depreciate and remove the "legacy" parts.
In practice though that's simply not possible. E.g. trivial example but you couldn't ever depreciate #include even though we have #import now.
Instead of "fixing" the language, there's written (not enforced by the compiler) documentation https://github.com/isocpp/CppCoreGuidelines - actually the first line is the perfect summary:
"Within C++ is a smaller, simpler, safer language struggling to get out." -- Bjarne Stroustrup
This is great documentation (and many parts are relevant to other languages) but many of its proscriptions cannot be enforced by the compiler so it will always be op
Read the rest
t in, mis interpreted or ignored.
Thanks for sharing, I’m unfamiliar with the nuances of Rust’s implementation of RAII as I’m primarily a modern C++ developer. Modern C++ mostly guarantees against leaks since it encourages the stack as much possible.
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
In A simple C implementation to stream H.264 to browser using WebRTCI kind of wish people would make more posts about c++ - idiomatic c++ today is totally different than the c++ knowledge i have from pre-2010.
The fact that c++ has changed so much in the past 10 years - it’s possible to write completely type and resource safe code in c++ now - this passed me by until a year or two ago when i attended a Bjarne talk.
Also the c++ folks have written up a core guidelines doc (this was the main topic of that Bjarne talk), and it’s really good https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
In Darker Corners of GoShowing the 15 most recent of 100 sources. Enable JavaScript to search and browse every indexed mention.