![\"mistake](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2019\/10\/mistake-968334_1280.jpg\")
<\/p>\nThe C++ core guidelines have about twenty naming and layout rules. A few of them are obvious; a few of them may be controversial. Let’s see what I mean.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
First of all, consistency is more important than these naming and layout rules. With this in mind, here is an overview of the rules.<\/p>\n
I will not write about the naming and layout rules of the C++ core guidelines, which already have sufficient explanations. I only write about the rules, which need additional wording or are often discussed in my seminars.<\/p>\n
I’m not a friend of commenting on each piece of code. Commenting on each piece of code may be a code smell because you code it too sophisticated. I’m more with the Python rule: explicit is better than implicit. I only write a comment if I have to apply a trick that is not apparent. For example, young professionals tend to remove curly braces from their code, such as you would remove redundant round braces from an arithmetic expression. If you don’t believe me, visit my seminars. But curly braces are essential to scope RAII<\/a> objects such as locks or smart pointers. Removing a curly brace from a lock may give you a slower program or a deadlock. In the end, many of my customers comment on using curly braces.<\/p>\n <\/p>\n What is terrible about comments is that they become out of date. By definition, this is not possible for the source code. It’s always up to date. As a freshman, my job was quite often to refactor legacy code. I often had no clue what it does, and I was pretty frustrated. To my rescue, I found a few comments. But the comments were completely outdated. It took me a while to recognize this; you can’t imagine how I felt. Comments have to be maintained as code but are often very sloppy maintained.<\/p>\n<\/p>\n Really? I thought since the last millennium, we were done with Hungarian Notation. I mean these good old times<\/em> in which our variables had no type. Hungarian Notation <\/a>is redundant with the type-checking of the compiler, contradicts generic programming, and – this is my main argument – becomes outdated as comments become outdated. Can you guess for what the following variable names stand?<\/p>\n <\/p>\n If you don’t know, here is the solution: Hungarian Notation. <\/a><\/p>\n This rule sounds strange, but we are already used to it. Giving a variable the name i or j <\/span>or the name T<\/span> will immediately make the code’s intention clear: i and j are indices, and T is a template type parameter. <\/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 self-evidence will not automatically hold for more extended contexts; therefore, you should use longer names.<\/p>\n Okay, this is an easy but quite helpful rule.<\/p>\n Can you read this example without any hesitation?<\/p>\n <\/p>\n Honestly, I often have issues when I type in a password having the number 0 or<\/span> the significant capital O. <\/span>Two years ago; it took me quite a time to log into a server. The automatically generated password had a character O. Let me give you two examples. Did you spot the two issues?<\/p>\n <\/p>\n p2<\/span> is a char <\/span> (1), and c<\/span> is not initialized (2).<\/p>\n With C++17, we got an exception to this rule: structured binding. Structured binding allows me to declare more than one name in one declaration (line 1).<\/p>\n Now, I can write the if statement with an initializer that is cleaner and more readable.<\/p>\n\nstd::<\/span>mutex mut;\r\n{ \/\/ necessary to manage the lifetime of the lock<\/span>\r\n std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lock(mut);\r\n ...\r\n}\r\n<\/pre>\n<\/div>\nNL.5: Don\u2019t encode type information in names<\/a><\/h3>\n
\nbBusy;\r\nfBusy;\r\npFoo;\r\nszLastName;\r\nfnFunction;\r\npszOwner;\r\nrgfpBalances;\r\nlpszBar;\r\ng_nWhells;\r\nm_whells;\r\n_whells;\r\n<\/pre>\n<\/div>\n
NL.7: Make the length of a name roughly proportional to the length of its scope<\/a><\/h3>\n
<\/span><\/p>\n\ntemplate<\/span><<\/span>typename<\/span> T><\/span> <\/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>\nNL.16: Use a conventional class member declaration order<\/a><\/h3>\n
\n
public<\/code><\/span> before protected<\/code><\/span> before private<\/code><\/span> order.<\/li>\n\nclass<\/span> X<\/span> { \/\/ bad<\/span>\r\npublic:<\/span>\r\n void<\/span> f();\r\npublic:<\/span>\r\n int<\/span> g<\/span>();\r\n \/\/ ...<\/span>\r\n};\r\n<\/pre>\n<\/div>\nNL.19: Avoid names that are easily misread<\/a><\/h3>\n
\nif<\/span> (readable(i1 +<\/span> l1 +<\/span> ol +<\/span> o1 +<\/span> o0 +<\/span> ol +<\/span> o1 +<\/span> I0 +<\/span> l0)) surprise();<\/pre>\n<\/div>\n
<\/span><\/p>\nNL.20: Don\u2019t place two statements on the same line<\/a><\/h3>\n
\nchar<\/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\nstd::<\/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 <\/span>\r\n<\/pre>\n<\/div>\nWhat’s next?<\/h2>\n