Item — HN Reader

I love this document, because I think that it's a perfect microcosm representing all the problems with the CPP style of doing things are.

The guidelines document is:

- Self admittedly incomplete

- Self admittedly outdated

- Extremely long

- Not targeted at developers first, but at analysis tool writers [1]

- Raises the question (to me, at least): Why doesn't this document exist since the nineties? What was going on there? What took so long?

And you can use this set of bullet points to basically describe everything that CPP does and all its complexity. Compare it to Python's pep8 and it's shameful, even. They tried to write some guidelines and the language was so big and bloated that they couldn't complete the work, plus the result is so inaccessible that most developers will simply ignore it completely.

I work professionally with CPP right now and all these issues are constant sources of pain to me. I want to like the language, but everything is always like this.

[1] "We do not expect you to memorize all the rules before trying to write code. One way of thinking about these guidelines is as a specification for tools that happens to be readable by humans."

1 comments

Do guidelines that claim to be complete and perfect actually reach that level? They preface this to cut off arguments were someone tries to slavishly follow rules even when inappropriate, something that is all too common in our industry.

It is long because they work on adding examples to each one and specify precisely what they mean. Striving to reach the level of precision a pedantic C++ developer might demand when ambiguity arises.

This document didn't exist in the 90s because the way we shared information was fundamentally different back then, the web sucked. Also, many of these relate to more recently learned lessons or specific things about C++11 and it would be odd to mandate time travel for one document.

Of course, I didn't mean this specific document, just a guidelines document similar to this, but for older versions of the language. I'm sorry for comparing to Python again, but it's a much younger language and it has had an official document equivalent to this one since 2001. Remember, the Core Guidelines project was announced in 2015, after C++14 was already in production systems all over the world.

C++11 has existed for more than a decade, it has already been superseded by 3 newer versions of the language that add a lot of new features (some of them incompatible with each other), yet for most of its existence there was no official guideline from the creators that explains how it should (and shouldn't) be used. And as far as I know, nothing like it existed for C++98. It's too little, too late. They clearly have some priorities regarding documentation that, as a user, I strongly disagree with.

Big organizations (EA, Unreal, Google, etc) can live with this -- they can afford to have their own, very restrictive standards on how to use the language. Most small organizations (in my experience) don't, either through lack of expertise, money, time, or will (or a combination of all), and their code is usually ugly, hacky, unstable, and hard to work on. This document only solves this problem insofar it exists as a very strong recommendation to buy ReSharper and just do whatever it says.

Yeah, there probably should have been more efforts to get something online early. But consider that the Bjarne, the original creator of the language, has published several books, that is where a lot of the guidance is from. Some of the books were out in the 90s and others wrote books too, I have one from Angelika Langer about IOStreams that is nearly 20 years old now, Scott Meyer a Microsoft compiler dev publishes stuff, Chandler Carruth a Google compiler dev publishes in depth talks. There is a lot of C++ material, just not much from a central source and not compiled into a single list. This makes it easier to go from a novice to an expert, and harder to become a novice in the first place

Before I got to your last paragraph, I was like "but big companies manage it fine" and you are right that it isn't readily approachable for non-expert small teams. There are things like Jason Turner's starter repos for C++ but he makes assumptions and even he went the book route, and is non-official.

I think a lot of this comes down to age and size. C++ is astronomically large. I don't want these to be excuses, you raise legitimate questions that need to be addressed, but I do think every language will deal with this when getting this large.

C++ just formed differently than a lot of languages. Most languages have 1 canonical source or at least had 1 source before the modern era of package managers and docs bundled with the language. C++ existed a good 25 years before package managers for languages became popular, so even getting libraries is hard. But it does mean that there are many package managing system for C++. Many sources of docs, and many implementations. You have freedom to pick your own at the cost of needing to know how to make such choice.

Compare to Ruby; Yukihiro Mastumoto (Matz) made a Ruby interpreter, CRuby the community sometimes calls it. Then someone remade it on the JVM, JRuby. Then they, some nebulous they that were invested in Ruby, made a standard for the core language. Then Twitter, Rubinius, some C# dudes, all made their own, but the CRuby implementation was the reference so deviations were bugs. The stand exists, but at 1500 pages (language and core library) or something like that the language is underspecified so everyone looks to Matz for answers, and maybe the Spec is updated with his blessing. At some point he blessed RubyGems as the de facto package manager and even though other exist they are generally ignored.

In C++ everyone follows the standard, even Bjarne Stroustrop the creator doesn't have his own compiler anymore. When there are deviations from the Standard everyone knows the standard is official and can read up enough from a variety of public sources. There is no single source of truth like Matz for Ruby, but there is no bottleneck on technical details either. The C++ standard is also much more detailed, coming in at two 3k page docs, 1 for the language and another for std lib even though both are much smaller than Ruby. Because there have been so many technical arguments there is much greater specificity and thought put into details. All of this openness comes with vagaries and difficulty getting into it.

C++ isn't a turnkey solution for a specific domain, it is a very general purpose tool for experts. Nothing is stopping someone from packaging as a turnkey solution and some the big companies you mentioned do exactly that for their internal development.