I strongly disagree with the prioritization of compile time and run time performance over maintainability. I can't count the number of times this has bitten me because of some premature optimization someone chose to write. Most of the time the "optimized" code is faster, but it was never a bottleneck to begin with, and is significantly harder to read/modify. Also, if compile time is so important to you, try using Meson as your build system.

Is compile time a real issue these days? I worked on a code base with thousands of source files and millions (in the 10s [corrected from 100s]) of lines of code 10 years ago and the build process took ~20 minutes. That's a long time, but it was 10 years ago and without a parallel build process. The code leveraged templates and other features of C++ that tend to lengthen compile times, too. Sure, we should strive for minimal compile time (it's expensive idle-time for a developer) but I'm not convinced it's worth allocating developer effort to except in egregious cases. Quality development that doesn't explicitly carve out time to focus on compile time should produce code that compiles in a reasonable time anyway.

In general (and for the majority of cases by a significant margin) I agree that maintainability should overrule run time performance. However as always there are tradeoffs to consider. If one is only going to use a program briefly or a small number of times maintainability becomes a lower priority.

None of these are unique to C++ so I recommend simplifying the title. Even compile time recommendations apply to many languages.

Also, it is strange for maintainability to be #4 when correctness is #1 because it is equally important for code to remain correct over time. There is nothing more frustrating than reopening issues over and over because people keep accidentally breaking things in unmaintainable code.

I don't think it is possible to state a general list of priorities such like this on all source code and all contexts. What is not apparent here is the context in which these priorities were stated. I could easily argue that maintainability (both reading and writing) is more important than runtime performance in any other given context.

What would be interesting is a more elaborate discussion of the priorities based on the context (which is unknown in this case).

How can you lose readibility to something else? Can't you comment what a tricky bit of code does? Full disclaimer, I'm a fairly novice programmer.

Those priorities are self-contradictory.

If you prioritize performance over maintainability, you're sacrificing long-term correctness, which is supposed to be your #1 priority.

PS. Also, "C++ Coding Guidelines"? This is neither coding guidelines, nor anything specific to C++.

"Make sure that what you assume won't compile actually doesn't compile."

How do I do that properly?

How do I test for undefined behaviour? I mean when I have code where I know that (ab-)using it in a certain way will trigger undefined behaviour, how do I test that?

I think that expressing these important points as priorities is missing a better way of looking at them.

I see them as tensions, the engineer's job and wisdom is in balancing these tensions

Except correctness. Code should be correct.

These coding guidelines might be a good idea overall but they do not seem very specific to C++. You could take the same guidelines and apply them to C, Ada, Obj-C, Pascal, etc.

If you look for C++ specific guidelines I suggest this: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...

I am saying this since C++ gives you a lot of power, but also a lot of responsibility and room for error making a more specific guide a very desirable thing.

Then, you don't use INT_MAX anymore, you use std::numeric_limits<int>::max()

undefined

Except in very special cases, I would suggest Maintainability be #2.