Indeed that not only you have to follow, everyone else on the project has to follow, as well as every newcomer and every piece of third-party code that is brought in.

"Avoid the parts you don't like" works best for one programmer working alone.

I had an instructor once that insisted on having a single exit point for all loops. "Never use break or continue or return from a loop." The argument was that understanding control flow is more complex when you don't have to deal with these things.

However, those things exist in the language. You can't just pretend nobody is going to use them, because there might be very good reasons to use them, especially in an imperative context.

(Though I suppose if you're grading 100 projects, such a rule might make it easier to get the code structured the same everywhere.)

In the world outside of that instructor's classroom, there are coding conventions which forbid certain things, with excellent reasons for doing so.

Back when ISO C++ was still staffed by people with useful ideas, they invented various more specialized, safer casts that refuse to do "off topic" conversions. These replace the "(type) expr" C casting notation.

A C++ coding convention document can cheerfully forbid C style casts; there isn't any reason to use them.

>only if you carefully constrain yourself to certain subsets of the language

I'm curious which subsets are included in this?

The answer(s) to that question take(s) the form of documents with many dozens or hundreds of pages. For example:

https://github.com/isocpp/CppCoreGuidelines

So not the sort of thing one can answer in-line in an HN comment.