C++ stagnated for many years, and many developers were confident that the language would have the same destiny as Cobol, Fortran, and VB6. On the contrary, against all odds, C++ was reborn from its ashes, and the new standards are significantly changing how the language is used.
The evolution of C++ by adding many interesting features does not mean that the C++98 standard was a bad one. Indeed, it gave us many interesting features to develop all kinds of applications. We can name many well-developed old C++ projects where the code is easy to maintain and evolve.
For example, the Doom game developed by John Carmack is one of the well-developed C++ games using only the basic mechanisms of the C++98 standard.
Here's a kind of testimonial we can find when searching for articles about Doom3:
I spent a bit of time going through the Doom3 source code. It’s probably the cleanest and nicest looking code I’ve ever seen.The key to success was not the richness of the language, but following some best practices that keep the code easy to read, maintain and evolve.
It’s true that not all developers have John Carmack’s skills, and maybe they need a more powerful language that helps them focus on the business layer of their applications. However, even if you use the most powerful programming language, if you adopt bad practices the code will be very difficult to understand or maintain.
And even with the most complicated programming language, like assembly, we can have nice code: the Prince of Persia game is proof that keeping it simple works even when using a low-level programming language.
Prince of Persia was originally developed by Jordan Mechner and released in 1989 for the Apple II; it represented a great leap forward in the quality of animation seen in video games. On April 17, 2012, Jordan Mechner released the source code of Prince of Persia. Exploring its codebase, we can notice that:
- The naming is easy to understand.
- The code is split into many small subroutines.
The 6502 assembly language is very low level, and to make the code easier to understand and maintain, the “Divide and Conquer” principle is applied. Indeed, the code is split into many small subroutines, which makes them easy to read and maintain. Here’s an example of a small subroutine from its source code:
Back to the new C++ standards: we can have beautiful code using all the new interesting features. On the other hand, if we follow bad practices, we can end up with code that’s not easy to understand and maintain. For example, this interesting post talks about the overuse of the auto keyword.
Bjarne Stroustrup and Herb Sutter are aware of the need for some basic guidelines to write efficient modern C++ code. A few years ago, they introduced the “C++ Core Guidelines”. Here’s the motivation behind introducing the guidelines, from their GitHub repository:
This document is a set of guidelines for using C++ well. The aim of this document is to help people to use modern C++ effectively. By "modern C++" we mean C++17, C++14, and C++11. 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 high-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.
Having the guidelines is good, but generally it’s difficult for a developer to spend hours doing a manual review to check these guidelines. For this reason, it’s better to use a tool to check them.
clang-tidy is the tool to use; it provides many interesting checks, including checks of some CppCoreGuidelines rules.
To summarize, it’s good to have these new C++ standards — thanks to all the actors of the C++ community who contributed to achieving this goal; it’s not really an easy task. However, without some basic best practices and guidelines, the code could quickly become unreadable, unmaintainable and difficult to evolve.