{"id":5365,"date":"2017-12-29T20:47:42","date_gmt":"2017-12-29T20:47:42","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/c-core-guidelines-rules-for-expressions-and-statements\/"},"modified":"2023-06-26T11:59:36","modified_gmt":"2023-06-26T11:59:36","slug":"c-core-guidelines-rules-for-expressions-and-statements","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/c-core-guidelines-rules-for-expressions-and-statements\/","title":{"rendered":"C++ Core Guidelines: Rules for Expressions and Statements"},"content":{"rendered":"

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.<\/p>\n

<\/p>\n

\"naming <\/p>\n

 <\/p>\n

I forget to mention two rules that are just called general. Here we are.<\/p>\n

ES.1: Prefer the standard library to other libraries and to \u201chandcrafted code\u201d<\/a><\/h3>\n

There is no reason to write a raw loop to sum up a vector of doubles:<\/p>\n

\n
int<\/span> max =<\/span> v.size();             \/\/ bad: verbose, purpose unstated<\/span>\r\ndouble<\/span> sum =<\/span> 0.0<\/span>;\r\nfor<\/span> (int<\/span> i =<\/span> 0<\/span>; i <<\/span> max; ++<\/span>i)\r\n    sum =<\/span> sum +<\/span> v[i];\r\n<\/pre>\n<\/div>\n
 <\/p>\n
You should just use the std::accumulate<\/span> algorithm from the STL.<\/p>\n
\n
auto<\/span> sum =<\/span> std::<\/span>accumulate(begin(a), end(a), 0.0<\/span>);   \/\/ good<\/span>\r\n<\/pre>\n<\/div>\n
 <\/p>\n
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!”<\/p>\n
Or to say it more directly: If you write a raw loop, you probably don’t know the algorithms of the STL.<\/p>\n<\/p>\n
ES.2: Prefer suitable abstractions to direct use of language features<\/a><\/h3>\n
The next d\u00e9j\u00e0 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 strstream<\/a>s. The participants had to maintain these functions and had, after one week, no idea what was going on.<\/p>\n
The main obstacle to don’t understanding the functionality was that the functionality was not based on the right abstraction.<\/p>\n
For example, compare the handmade function for reading a std::istream. <\/span> <\/p>\n
\n
char<\/span>**<\/span> read1<\/span>(istream&<\/span> is, int<\/span> maxelem, int<\/span> maxstring, int<\/span>*<\/span> nread)   \/\/ bad: verbose and incomplete<\/span>\r\n{\r\n    auto<\/span> res =<\/span> new<\/span> char<\/span>*<\/span>[maxelem];\r\n    int<\/span> elemcount =<\/span> 0<\/span>;\r\n    while<\/span> (is &&<\/span> elemcount <<\/span> maxelem) {\r\n        auto<\/span> s =<\/span> new<\/span> char<\/span>[maxstring];\r\n        is.read(s, maxstring);\r\n        res[elemcount++<\/span>] =<\/span> s;\r\n    }\r\n    nread =<\/span> &<\/span>elemcount;\r\n    return<\/span> res;\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
In contrast, how easy is the following function to consume?<\/p>\n
\n
vector<<\/span>string><\/span> read2(istream&<\/span> is)   \/\/ good<\/span>\r\n{\r\n    vector<<\/span>string><\/span> res;\r\n    for<\/span> (string s; is >><\/span> s;)\r\n        res.push_back(s);\r\n    return<\/span> res;\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
The right abstraction often means you do have not to think about ownership, such as in the function read1<\/span>. This will not hold for the function read2. The caller of read1<\/span> is the owner of result<\/span> and has to delete it.<\/p>\n
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.<\/p>\n
Anyway, I will continue presenting the rules because good names a probably the key to making code readable, understandable, maintainable, and extensible, …<\/p>\n
Here are the first six rules.<\/p>\n
ES.5: Keep scopes small<\/a><\/span><\/h3>\n
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.<\/p>\n
ES.6: Declare names in for-statement initializers and conditions to limit scope<\/a><\/span><\/h3>\n
Since the first C++ standard, we can declare a variable in a for<\/span> statement. Since C++17, we can declare variables in an if<\/span> or a switch<\/span> statement.<\/p>\n
\n
std::<\/span>map<<\/span>int<\/span>,std::<\/span>string><\/span> myMap;\r\n\r\nif<\/span> (auto<\/span> result =<\/span> myMap.insert(value); result.second){  \/\/ (1)<\/span>\r\n    useResult(result.first);  \r\n    \/\/ ...<\/span>\r\n} \r\nelse<\/span>{\r\n    \/\/ ...<\/span>\r\n} \/\/ result is automatically destroyed                 \/\/ (2)<\/span>\r\n<\/pre>\n<\/div>\n
 <\/p>\n
The variable result<\/span> (1) is only valid inside the if<\/span> and else<\/span> branches of the if<\/span> statement. result<\/span> 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).<\/p>\n
 <\/p>\n
\n
std::<\/span>map<<\/span>int<\/span>,std::<\/span>string><\/span> myMap;\r\nauto<\/span> result =<\/span> myMap.insert(value)   \/\/ (3)<\/span>\r\nif<\/span> (result.second){  <\/span>\r\n    useResult(result.first);  \r\n    \/\/ ...<\/span>\r\n} \r\nelse<\/span>{\r\n    \/\/ ...<\/span>\r\n} \r\n<\/pre>\n<\/div>\n
 <\/p>\n
ES.7: Keep common and local names short, and keep uncommon and nonlocal names longer<\/a><\/span><\/h3>\n
This rule sounds strange, but we are already used to it. Giving a variable the name i or j <\/span>or giving a variable the name T<\/span> will make the code’s intention immediately clear: i<\/span> and j<\/span> are indices, and T<\/span> is a type parameter of a template.
<\/span><\/p>\n
\n
template<\/span><<\/span>typename<\/span> T><\/span>    \/\/ good<\/span>\r\nvoid<\/span> print(ostream&<\/span> os, const<\/span> vector<<\/span>T>&<\/span> v)\r\n{\r\n    for<\/span> (int<\/span> i =<\/span> 0<\/span>; i <<\/span> v.size(); ++<\/span>i)\r\n        os <<<\/span> v[i] <<<\/span> '\\n'<\/span>;\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
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. <\/p>\n
ES.8: Avoid similar-looking names<\/a><\/span><\/h3>\n
Can you read this example without any hesitation?<\/p>\n
\n
if<\/span> (readable(i1 +<\/span> l1 +<\/span> ol +<\/span> o1 +<\/span> o0 +<\/span> ol +<\/span> o1 +<\/span> I0 +<\/span> l0)) surprise();\r\n<\/pre>\n<\/div>\n
 <\/p>\n
Honestly, I often have problems with the number 0<\/span> and the significant capital O<\/span>. 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 <\/span> O.<\/span><\/p>\n
ES.9: Avoid ALL_CAPS<\/code> names<\/a><\/span><\/h3>\n
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.<\/p>\n
\n
\/\/ somewhere in some header:<\/span>\r\n#define NE !=<\/span>\r\n\r\n\/\/ somewhere else in some other header:<\/span>\r\nenum<\/span> Coord { N, NE, NW, S, SE, SW, E, W };\r\n\r\n\/\/ somewhere third in some poor programmer's .cpp:<\/span>\r\nswitch<\/span> (direction) {\r\ncase<\/span> N:\r\n    \/\/ ...<\/span>\r\ncase<\/span> NE:\r\n    \/\/ ...<\/span>\r\n\/\/ ...<\/span>\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
ES.10: Declare one name (only) per declaration<\/a><\/h3>\n
Let me give you two examples. Did you spot the two issues?<\/p>\n
 <\/p>\n
\n
char<\/span>*<\/span> p, p2;\r\nchar<\/span> a =<\/span> 'a'<\/span>;\r\np =<\/span> &<\/span>a;\r\np2 =<\/span> a;                              \/\/ (1)<\/span>\r\n\r\nint<\/span> a =<\/span> 7<\/span>, b =<\/span> 9<\/span>, c, d =<\/span> 10<\/span>, e =<\/span> 3<\/span>;  \/\/ (2)<\/span>\r\n<\/pre>\n<\/div>\n
 <\/p>\n
p2<\/span> is just a char <\/span> (1), and c<\/span> is not initialized (2).<\/p>\n
With C++17, we got one exception to this rule: structured binding.<\/p>\n
Now, I can write the if statement with an initializer in rule ES.6 even cleaner and more readable.<\/p>\n
 <\/p>\n
\n
std::<\/span>map<<\/span>int<\/span>,std::<\/span>string><\/span> myMap;\r\n\r\nif<\/span> (auto<\/span> [iter, succeeded] =<\/span> myMap.insert(value); succedded){  \/\/ (1)<\/span>\r\n    useResult(iter);  \r\n    \/\/ ...<\/span>\r\n} \r\nelse<\/span>{\r\n    \/\/ ...<\/span>\r\n} \/\/ iter and succeeded are automatically destroyed            \/\/ (2)<\/span>\r\n<\/pre>\n<\/div>\n
 <\/p>\n
What’s next?<\/h2>\n
Of course, I will continue with the rules regarding declarations in my next post.<\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p><\/p>\n","protected":false},"excerpt":{"rendered":"
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.<\/p>\n","protected":false},"author":21,"featured_media":5364,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[372],"tags":[497],"class_list":["post-5365","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-modern-c","tag-declarations"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5365","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/comments?post=5365"}],"version-history":[{"count":1,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5365\/revisions"}],"predecessor-version":[{"id":6845,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5365\/revisions\/6845"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/5364"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=5365"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=5365"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=5365"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}