HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
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++

Learning & Reference
Explore on GitHubRead Hacker News discussions
85Distinct people
100Mentions
1Explicit recommenders
45.5KGitHub stars
REPOSITORY AT A GLANCE

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

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, 5:04:57 PM 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.

051015202015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 21 mentions; 11 submissions, 10 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 20 mentions; 2 submissions, 18 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 12 mentions; 0 submissions, 12 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 16 mentions; 3 submissions, 13 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments. Incomplete calendar period.2026*

* 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
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC211110
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC20218
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC12012
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC16313
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC606
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC1019
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC303
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC505
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC303
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC303
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC110

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 GitHub

What Hacker News says

20 sources
koja86·Dec 29, 2016
You might find this project kind of interesting: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... As a day-to-day C++ practitioner I like it. ...Yet I am not fully convinced that the general idea of language evolution implemented as ruleset outside of the language itself is the way to go. Seems more like band-aid to me and made me start to think about concept of programming language's life cycle in context of Darwinian evolution - once either legacy compatibility burden is too big or that particular biotope of specific problems the language solves better than others vanishes/changes the language dies out. My particular issue with C++ is that it's complexity, longevity and evolution made possible for widespread bad-practices as not every C++ developer evolved as much as the language itself and it's general public understandi
Read the rest
ng. (Some current best-practices were simply not always widely known or accepted.) I would even go as far to say that most of existing C++ code is crap (at least from standpoint of today "modern" C++). And that's why I am both eagerly looking to "next generation" being shaped up by people who has (hopefully) learnt from past mistakes and used by people who care (itching to give Rust a ride once it stabilizes just a bit more) and also occasionally digging in the history for possible gems that I might not able to see without my current experience (platonic weekends-only relationship with Haskell, Lisp being right there at top of my TODO list). EDIT: Removed the sir.
In C++17 – better than you might think
stinos·Dec 4, 2016
the "Modern C++" community Could you describe what/who you think this is, because I don't really see a community as a whole for who the points you make are valid. Sure there's some crazy purists everywhere, but in general I don't think it's as bad as you mention. Then again might be biased because I write way more C++ than C. I know cherry-picking isn't usually the most fair way to discuss, but some things really strike me as unfair so I can't help it. obsessed with "best practices" not sure if this is really bad? When pushed to the extreme it is, but that goes for anything extreme, but I don't really feel the C++ community is like that. At least I've read many times things in the spirit of 'best practices ar good, follwing them blindly is not'. Also anecdotally from all colleagues I ever worked with those with some healthy amount of (as
Read the rest
in, still being able to think critically) obsession with trying to Do The Right Thing, always wrote better code than those who lacked that OOP was oversold it surely was, but imo one of the things modern C++ teaches us is exactly that: OOP overuse is bad and you don't have to use OOP at all in C++ if you don't want to "some bloke named Herb says X, so you must follow him" sort of attitude which is in turn countered by an attitude of questioning everything, no matter if the author is called Herb or Bjarne, and I don't think I'm dreaming that (at least I've seen many questions on SO starting with 'in xxx Herb says y, wtf is that all bout?'). On the other hand, those guys' advice is usually golden so following it won't hurt much, as long as you don't blindly follow it. I just want to use the features of the language that make it easier and simpler to solve a problem more efficiently in the end everybody wants this I guess, and I do have the feeling that when searching for questions to typical problems I usually do get an answer telling me exactly what to use. Also take https://github.com/isocpp/CppCoreGuidelines for example: sure theres a whole lot of info but it does give a ton of good/bad examples, plus reasoning behind it
In C++ confessions of a C developer
chubot·Nov 22, 2016
I'm struggling with this too... I'm implementing a shell, and on the one hand I've been looking at ancient C code in bash, dash, zsh, mksh, etc. That's clearly not the right way to do it, with raw strings, pointers, and globals everywhere. It's ridiculously verbose and error prone. All recursive parsers in C seem to use setlongjmp for error handling. They have weird memory management with stack allocated strings and globals too, because memory management in C is such a pain. I tend to like "C with classes". When I started working at Google, the C++ style was a breath of fresh air over what I had seen in the game industry (this was in 2005, so C++ was in a very different state). It was very much C with classes: no exceptions, no iostreams, no operator overloading, no default copy constructors or assignment, in/out params, etc. (Late
Read the rest
ly it has been trending toward "modern C++", albeit with custom internal libraries for errors and such) Then C++ 11 came out -- you really can't do without auto and range for loops. It looks like strongly typed enums are useful, and some STL stuff. For recursive parsers, exceptions instead of setlongjmp seems useful too (setlongjmp doesn't work with destructors AFAIK). I'm scared of R-Value refs and move semantics -- I don't know anything about those. I guess my point is that it's 2016 and it's hard to know if there was a goldilocks moment. Google was using a restricted dialect of C++03 which I think was pretty great and built a lot of real software, but it's hard to say that C++11 didn't add anything useful. I'm sure the Google style diverges pretty wildly from Bjarne's new effort of C++ core guidelines, which I need to look into more: https://google.github.io/styleguide/cppguide.html https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... It seems like the LLVM codebase really knows what it's doing in terms of C++, which makes sense, but honestly it's fairly complex for what I want to do. So I think we are just stuck with all these local dialects, which makes code reuse a problem.
In Help me sort out the meaning of “{}” as a constructor argument
pjmlp·Oct 17, 2016
They are here: https://isocpp.org/ http://cppcon.org/ https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... http://erdani.com/index.php/books/modern-c-design/ https://msdn.microsoft.com/en-us/library/hh279654.aspx http://stroustrup.com/Tour.html http://elementsofprogramming.com/book.html Most of the C++ bugs I found happened to be written by former C developers that disregard using C++ stronger type safety, RAII, the standard library containers and usually use naked pointers alongside malloc() and free(). And that is the biggest problem with C++, its copy-paste compatibility with C, which allowed its adoption by C compiler vendors, but made it as safe as C when developers disregard best practices.
In WTF is a container?
nercury·Aug 20, 2016
I guess Rust may seem more complex, if you know C++ well, but from the side it may not seem like it. For example, C++ Core Guidelines [0] is longer than Rust Book. Core Guidelines is itself a great example of things one needs to keep in the head while writing C++ code. Look at implementation of something as basic as optional<T> [1]. The amount of things one needs to know is so high most C++ developers would never attempt it. [0]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... [1]: https://github.com/akrzemi1/Optional/blob/master/optional.hp...
In Rust: Systems Programming for Everyone
voyou·Jun 13, 2016
Pointer arithmetic isn't "something that I will surely never want to do"; it's something you want to do all the time in C (and therefore in C++ written in a more C-like style). Illegitimate uses of pointer arithmetic, such as your example, are only easy to detect in trivial cases like yours. I assume this is why no one has bothered implementing a warning for this special case. In C++, directly using pointers to access arrays is often discouraged, in favour of using the standard collection types and their associated iterator types. So in code that follows this style, it is possible to warn about uses of pointer arithmetic, and the core C++ guidelines do suggest such a warning. But the guidelines also point out that "this rule would generate a huge number of false positives if applied to an older code base": https://github.com/isocpp/CppCor
Read the rest
eGuidelines/blob/master/CppC...
In “Safe C++ Subset” Is Vapourware
jbandela1·May 19, 2016
For some guidelines take a look at https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... If you want to look up some information about the C++ library, look at http://en.cppreference.com/w/ Here is my advice if you are learning C++ for the first time. 1. Use the latest released version of either GCC, Clang (preferrable) or Visual C++ if you want the best IDE 2. Do NOT start off with pointers. Doing so will only confuse and frustrate you. 3. Use std::string and std::vector. Learn about the std::algorithm. Learn about lambdas 4. Learn about RAII, constructors, and destructors. Focus on invariants - how you set them up and how you maintain them. 5. Learn about exceptions and exception safety 6. Learn about references and polymorphism 7. Learn about dynamic memory and std::unique_ptr 8. Learn about copy/move construction and assignm
Read the rest
ent 9. Learn about std::shared_ptr 10. Implement your own version of std::vector. You will learn about memory management and pointers by implementing the iterators. 11. Learn about std::list and std::forward_list 12. Implement your versions of both. You will learn a lot about pointers. 13. Analyze the exception safety of your implemented versions of std::vector, std::list, and std::forward_list. Make sure you do not leak memory or end up in an invalid state. This should get you acquainted with the basics. Now here is how to test yourself in various areas to see how comfortable you are. Templates: Implement std::tuple Memory management: Learn about memory allocation strategies and implement in an allocator that you can use with std::vector or std::list Unions: Implement std::string small-string optimization Atomics/memory model: Implement an atomic shared_ptr, where multiple threads can access the same shared_ptr atomically
In Ask HN: C++ for Rubyists/Minimalists
topspin·Apr 18, 2016
Working around a broken API is not premature optimization. Stroustrup et al. point out the same problem with std::endl[1] and advise the same remedy as the presentation linked here. Conflating EOL with flush() was a mistake the moment it was first written. Systems programming languages aren't about easy troubleshooting. C/C++ APIs should be performant by default because when they are not we end up working around them, often badly. If I want the stream flushed I'll configure it to behave as such or I'll call flush explicitly. Any other mindset belongs in Python, Java or some other higher level language. [1] https://github.com/isocpp/CppCoreGuidelines/issues/357#issue...
In Stop Using Std::endl [video]
dbaupp·Mar 7, 2016
Even supposing that Rust and C++ have the same level of complexity, the style and consequences of their complexity are wildly different. A lot of the various pieces of complexity of C++ needs to be held in the head of a human who is writing it, but most of Rust's complexity can be left to the compiler and humans only need to page in the pieces the compiler points out. C++'s complexity often manifests as, basically, a list of rules[1] that the programmer should follow perfectly to reduce the risk of their compiled code not doing what they want. A lot of C++'s hairiest complexity is driven by weird interactions between "independent" language features (often driven in part by the goal of C backwards compatibility), and other complexities are just driven by the C-style mindset of hoping/requiring that programmers don't make mistakes. A lot of
Read the rest
these (especially in the latter category) result in code that compiles fine, but misbehaves at runtime. On the other hand, neither of these categories apply to Rust: Rust's complexity is mostly pushed into the compiler, which tries to flag problems early. Instead of having a list of rules they need to follow themselves, programmers have a compiler that checks their code against the list (the result ends up being somewhat similar to the C++ core guidelines). Computers are far less fallible than humans, and so programmers can have more trust that they won't miss something. Of course, this definitely can have the effect of making writing code seem hard because it forces the programmer to resolve/defend against a lot of errors up front. [1]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... (I should say that a lot of these rules are great, and apply more broadly than just C++, but significant chunks are "work-arounds" for things C++ compilers don't check and things that the standard library often doesn't help with either, particularly in the resource management and concurrency sections.)
In Ill-Advised C++ Rant, Part 2

Showing the 15 most recent of 20 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.