In this page, I will introduce some best practice recommended by Google. We should write readable, efficient, and extendable codes. <\/p>\n\n\n\n
It can be more flexible than If no order is required, consider https:\/\/github.com\/google\/googletest\/blob\/master\/googletest\/docs\/faq.md#why-should-test-suite-names-and-test-names-not-contain-underscore<\/a><\/p>\n\n\n\n If possible, use https:\/\/github.com\/isocpp\/CppCoreGuidelines\/blob\/master\/CppCoreGuidelines.md#Res-for-range<\/a><\/p>\n\n\n\n When using a pointer (or reference) to a container, it usually contains two levels of pointer arithmetic. Consider using Two levels of pointer arithmetic makes it really hard for compilers to do analysis. When read or write data in loops, Use\u00a0 Suggest using\u00a0 https:\/\/github.com\/isocpp\/CppCoreGuidelines\/blob\/master\/CppCoreGuidelines.md#r11-avoid-calling-new-and-delete-explicitly<\/a><\/p>\n\n\n\n Avoid https:\/\/abseil.io\/tips\/3<\/a><\/p>\n\n\n\n Separate headers by sections. Within each section the includes should be ordered alphabetically. No UNIX directory aliases As an example, in Google’s C++ Stype Guide#Names_and_Order_of_Includes<\/a><\/p>\n\n\n\n https:\/\/abseil.io\/tips\/153<\/a>, https:\/\/abseil.io\/tips\/130<\/a><\/p>\n\n\n\n In C++, lookup on an unqualified name ( If https:\/\/abseil.io\/tips\/130<\/a><\/p>\n\n\n\n Level Depth is better to be no more than 2, which could be achieved by early return or separate functions.<\/p>\n\n\n\n Declaration comments describe use of the function (comments should use the indicative mood like “Returns the area”, rather than the imperative “Return the area”; definition comments describe implementation details.<\/p>\n\n\n\n Prefer Note that https:\/\/abseil.io\/tips\/1<\/a><\/p>\n\n\n\n Prefer enum over boolean parameters. https:\/\/abseil.io\/tips\/94<\/a><\/p>\n\n\n\n Prefer return value over output parameters (please refer to StatusOr<\/a> in protobuf, the Also output parameters should be after input parameters.<\/p>\n\n\n\n Same as string_view over Usually pass https:\/\/abseil.io\/tips\/93<\/a><\/p>\n\n\n\n Call reserve if the final size is known to avoid repeated allocation and the corresponding copy\/moves. <\/p>\n\n\n\n Since if a reallocation happens, old values might be copied into the new memory.<\/p>\n\n\n\n Prefer https:\/\/abseil.io\/tips\/112<\/a>, https:\/\/abseil.io\/tips\/65<\/a><\/p>\n\n\n\n It is very common that people want to define static const variables in the global namespace. <\/p>\n\n\n\n Before C++17, use extern const variables.<\/p>\n\n\n\n After C++17, use inline variables.<\/p>\n\n\n\n https:\/\/www.learncpp.com\/cpp-tutorial\/global-constants-and-inline-variables\/<\/a><\/p>\n\n\n\nEXPECT_EQ<\/code>.<\/p>\n\n\n\nEXPECT_THAT(Foo(), ElementsAre(1, Gt(0), _, 10));<\/code><\/pre>\n\n\n\nUnorderedElementsAre<\/code>.<\/p>\n\n\n\nTest Suite Names and Test Names not Contain Underscore<\/h2>\n\n\n\n
Prefer Range-Based Loops<\/h2>\n\n\n\n
for (const auto i& : v)<\/code> rather than index-based loops for better performance (same reason as avoiding vector<T>&<\/code> below). <\/p>\n\n\n\nAvoid
vector<T>&<\/code> or string &<\/code><\/h2>\n\n\n\nabsl::Span<\/code> or absl::string_view<\/code> instead.<\/p>\n\n\n\nvoid Foo(vector<T> &a) {\n a[0] = 1; \/\/ actually it is a->data()[0] = 1\n}\n\n\/\/ method 1\nvoid Foo(absl::Span<T> a) {\n a[0] = 1; \/\/ data[0]=1, only one level of pointer arithmetic\n}\n\n\/\/ method 2\nvoid Foo(vector<T> &a) {\n absl::Span<T> b(a);\n for (...) {\n b[i] = 1;\n }\n}<\/code><\/pre>\n\n\n\nabsl::Span<\/code> becomes much faster because of vectorization.<\/p>\n\n\n\nAvoid\u00a0
[]<\/code>\u00a0parameters, prefer\u00a0span<\/code><\/h2>\n\n\n\nabsl::Span<\/code>\u00a0instead for better readability and safety.<\/p>\n\n\n\nAvoid Calling\u00a0
new<\/code>\u00a0&\u00a0delete<\/code>\u00a0Explicitly<\/h2>\n\n\n\nmake_unique<\/code>\u00a0instead. <\/p>\n\n\n\nStrCat<\/code><\/h2>\n\n\n\nfoo + bar + baz<\/code>, use absl::StrCat(foo, bar, baz)<\/code> instead. Since for chains of n<\/code> string concatenations, in the worst case, it requires O(n)<\/code> reallocations.<\/p>\n\n\n\nOrder of Includes<\/h2>\n\n\n\n
.<\/code> (the current directory) or ..<\/code> (the parent directory) please. <\/p>\n\n\n\ndir2\/foo2<\/var>.h<\/code> (the declaration if applicable)<\/li>.h<\/code> extension), e.g., <unistd.h><\/code>, <stdlib.h><\/code>.<\/li><algorithm><\/code>, <cstddef><\/code>.<\/li>.h<\/code> files.<\/li>.h<\/code> files<\/li><\/ol>\n\n\n\nfoo\/server\/fooserver.cc<\/code><\/p>\n\n\n\n#include \"foo\/server\/fooserver.h\"\n\n#include <sys\/types.h>\n#include <unistd.h>\n\n#include <string>\n#include <vector>\n\n#include \"base\/basictypes.h\"\n#include \"base\/commandlineflags.h\"\n#include \"foo\/server\/bar.h\"<\/code><\/pre>\n\n\n\nNamespace<\/h2>\n\n\n\n
using-directive (using namespace foo;)<\/code> <\/li>using-declarations, like using foo::bar;<\/code>).<\/li>using-declarations<\/code> and namespace aliases; in other cases, please try to avoid fully qualifying unless you must to make it compile;<\/li>std<\/code>, util<\/code>, or testing<\/code>.<\/li><\/ol>\n\n\n\nnamespace foo {\nusing ::foo1::bar::Baz;\nnamespace baz = ::foo2::bar::baz;\n}<\/code><\/pre>\n\n\n\nNamespace Lookup<\/h2>\n\n\n\n
namespace foo {\nnamespace bar {\n\nvoid Func() {\n Baz::HaHa b;\n}\n\n} \/\/ namespace bar\n} \/\/ namespace foo\n<\/code><\/pre>\n\n\n\nBaz::HaHa<\/code>) will search expanding scopes for a symbol of the same name: first in Func<\/code> (the function), then in bar<\/code>, then in foo<\/code>, then in the global namespace. <\/p>\n\n\n\nBaz<\/code> refers to a global namespace and in bar<\/code> there is another namespace called Baz<\/code>, but without HaHa<\/code> defined, then building will fail, since namespace lookup looked into ::foo::bar::Baz<\/code> first, failed, and stopped. Use fully qualified ::Baz::HaHa<\/code> will solve the problem.<\/p>\n\n\n\nReduce Double-Negatives<\/h2>\n\n\n\n
\/\/ bad\nif (!disable_b) {\n DoA();\n} else {\n DoB();\n}\n\n\/\/ good\nif (enable_b) {\n DoB();\n} else {\n DoA();\n}<\/code><\/pre>\n\n\n\nReduce Nesting Levels<\/h2>\n\n\n\n
Function Comments<\/h2>\n\n\n\n
string_view<\/code><\/h2>\n\n\n\nstring_view<\/code> over const char*<\/code> or const string&<\/code> as function parameters. <\/p>\n\n\n\nstring_view<\/code> is not necessarily NUL-terminated.<\/p>\n\n\n\nAvoid Boolean Parameters<\/h2>\n\n\n\n
Foo(Feature::kA)<\/code> makes more sense than Foo(\/*enable_A*\/true)<\/code>.<\/p>\n\n\n\nOutput Parameters<\/h2>\n\n\n\n
StatusOr<\/code> on Abseil is not open sourced yet). <\/p>\n\n\n\nPrefer
span<\/code> as Function Parameters<\/h2>\n\n\n\nconst char*<\/code> or const string&<\/code>, prefer span<const T><\/code> over const T*<\/code> or const vector<T>&<\/code> as function parameters. <\/p>\n\n\n\nspan<\/code> or string_view<\/code> by value, since it is not always faster to pass a pointer. See Copy Elision and Pass-by-value in https:\/\/abseil.io\/tips\/117<\/a>.<\/p>\n\n\n\nQualifying
auto<\/code> <\/h2>\n\n\n\nconst auto&<\/code> or auto&<\/code> unless a copy is needed;<\/li>const auto&<\/code> unless you need to modify data;<\/li>const auto*<\/code> or auto*<\/code> to make pointer explicit;<\/li><\/ol>\n\n\n\nchar num = 'a';\nchar* p1 = #\nauto p2 = p1; \/\/ p2 is 'char*'\nauto* p3 = p1; \/\/ p3 is 'char*' (same as bare auto)<\/code><\/pre>\n\n\n\nReserve Size in Advance<\/h2>\n\n\n\n
Prefer
push_back<\/code> over emplace_back<\/code><\/h2>\n\n\n\npush_back<\/code> over emplace_back<\/code> unless the performance matters. Since emplace_back<\/code> is too powerful. <\/p>\n\n\n\nstd::vector<vector<int>> vec;\nvec.push_back(1<<20); \/\/ compile error\nvec.emplace_back(1<<20); \/\/ no errors until run-time<\/code><\/pre>\n\n\n\nGlobal Constants<\/h2>\n\n\n\n
cc<\/code> file), since the order of initialization between translation units is unspecified.<\/li>constexpr<\/code>. <\/li><\/ol>\n\n\n\nConstants in Header<\/h4>\n\n\n\n
\/\/ constants.h\n#ifndef CONSTANTS_H\n#define CONSTANTS_H\n \nnamespace constants\n{\n \/\/ since the actual variables are inside a namespace, the forward declarations need to be inside a namespace as well\n extern const double pi;\n extern const double avogadro;\n extern const double my_gravity;\n}\n \n#endif\n\n\/\/ constants.cc\n#include \"constants.h\"\n \nnamespace constants\n{\n \/\/ actual global variables\n extern const double pi { 3.14159 };\n extern const double avogadro { 6.0221413e23 };\n extern const double my_gravity { 9.2 }; \/\/ m\/s^2 -- gravity is light on this planet\n}<\/code><\/pre>\n\n\n\n#ifndef CONSTANTS_H\n#define CONSTANTS_H\n \n\/\/ define your own namespace to hold constants\nnamespace constants\n{\n inline constexpr double pi { 3.14159 }; \/\/ note: now inline constexpr\n inline constexpr double avogadro { 6.0221413e23 };\n inline constexpr double my_gravity { 9.2 }; \/\/ m\/s^2 -- gravity is light on this planet\n \/\/ ... other related constants\n}\n#endif<\/code><\/pre>\n\n\n\nConstants in Source<\/h4>\n\n\n\n
constexpr int kNum = 42;\nconstexpr char kStr[] = \"hello\";\nconstexpr std::string_view kAnotherStr = \"world\";<\/code><\/pre>\n\n\n\n