There are many rules in the C++ Core Guidelines dealing with expressions and statements. To be precise, there are more than 50 rules about declarations, expressions, statements, and arithmetic expressions.
I forget to mention two rules that are just called general. Here we are.
There is no reason to write a raw loop to sum up a vector of doubles:
You should just use the std::accumulate algorithm from the STL.
This rule reminds me to a sentence from Sean Parent at CppCon 2013: “If you want to improve the code quality in your organization, replace all your coding guidelines with one goal: No raw loops!”
Or to say it more directly: If you write a raw loop, you probably don’t know the algorithms of the STL.
The next déjà vu. In one of my last C++ seminars, I had a long discussion followed by an even longer analysis of a few quite sophisticated and handmade functions for reading and writing strstreams. The participants had to maintain these functions and had, after one week, no idea what was going on.
The main obstacle to don’t understanding the functionality was that the functionality was not based on the right abstraction.
For example, compare the handmade function for reading a std::istream.
In contrast, how easy is the following function to consume?
The right abstraction often means you do have not to think about ownership, such as in the function read1. This will not hold for the function read2. The caller of read1 is the owner of result and has to delete it.
A declaration introduces a name into a scope. To be honest, I’m biased. On the one hand, the following rules are a little bit borrowing for you because they are pretty obvious. On the other hand, I know a lot of codebases that permanently break these rules. For example, I had a discussion with a former Fortran programmer, who stated: Each variable should have exactly three characters.
Anyway, I will continue presenting the rules because good names a probably the key to making code readable, understandable, maintainable, and extensible, …
Here are the first six rules.
If a scope is small, you can put it on a screen and get an idea of what is happening. If a scope becomes too big, you should structure your code into functions or objects with methods. Identify logical entities and use self-explanatory names in your refactoring process. Afterward, it is a lot easier to think about your code.
Since the first C++ standard, we can declare a variable in a for statement. Since C++17, we can declare variables in an if or a switch statement.
The variable result (1) is only valid inside the if and else branches of the if statement. result will not pollute the outer scope and will be automatically destroyed (2). This can not be done before C++17. You have to declare the result in the outer scope (3).
This rule sounds strange, but we are already used to it. Giving a variable the name i or j or giving a variable the name T will make the code’s intention immediately clear: i and j are indices, and T is a type parameter of a template.
There is a meta-rule behind this rule. A name should be self-explanatory. In a short context, you get what the variable means with a glance. This will not automatically hold for more extended contexts; therefore, you should use longer names.
Can you read this example without any hesitation?
Honestly, I often have problems with the number 0 and the significant capital O. Depending on the font used; it looks similar. Two years ago, logging into a server took me quite a while. My automatically generated password had a character O.
If you use, ALL_CAPS macro substitution may kick in because ALL_CAPS is commonly used for macros. The following program snippet may have a little surprise involved.
Let me give you two examples. Did you spot the two issues?
p2 is just a char (1), and c is not initialized (2).
With C++17, we got one exception to this rule: structured binding.
Now, I can write the if statement with an initializer in rule ES.6 even cleaner and more readable.
Of course, I will continue with the rules regarding declarations in my next post.
Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, moon, and Philipp Lenk.
Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.
|My special thanks to Embarcadero|
|My special thanks to PVS-Studio|
|My special thanks to Tipi.build|
|My special thanks to Take Up Code|
|My special thanks to SHAVEDYAKS|
I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
- Embedded Programmierung mit modernem C++ 12.12.2023 – 14.12.2023 (Präsenzschulung, Termingarantie)
Standard Seminars (English/German)
Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.
- C++ – The Core Language
- C++ – The Standard Library
- C++ – Compact
- C++11 and C++14
- Concurrency with Modern C++
- Design Pattern and Architectural Pattern with C++
- Embedded Programming with Modern C++
- Generic Programming (Templates) with C++
- Clean Code with Modern C++
- Phone: +49 7472 917441
- Mobil:: +49 176 5506 5086
- Mail: schulung@ModernesCpp.de
- German Seminar Page: www.ModernesCpp.de
- Mentoring Page: www.ModernesCpp.org
Modernes C++ Mentoring,