C++最佳实践 | 2. 代码风格

举报
C语言与CPP编程 发表于 2022/09/30 00:15:15 2022/09/30
【摘要】 本系列是开源书C++ Best Practises[1]的中文版,全书从工具、代码风格、安全性、可维护性、可移植性、多线程、性能、正确性等角度全面介绍了现代C++项目的最佳实践。本文是该系列的第二篇。 C++最佳实践: 1. 工具 2. 代码风格(本文) 3. 安全性 4. 可维护性 5...

本系列是开源书C++ Best Practises[1]的中文版,全书从工具、代码风格、安全性、可维护性、可移植性、多线程、性能、正确性等角度全面介绍了现代C++项目的最佳实践。本文是该系列的第二篇。

C++最佳实践:

1. 工具

2. 代码风格(本文)

3. 安全性

4. 可维护性

5. 可移植性及多线程

6. 性能

7. 正确性和脚本

代码风格

代码风格最重要的是一致性,其次是遵循C++程序员习惯的阅读风格。

C++允许任意长度的标识符名称,因此在命名时没必要非要保持简洁,建议使用描述性名称,并在风格上保持一致。

  • CamelCase(驼峰命名法)

  • snake_case(蛇形命名法)

这两种是很常见的命名规范,snake_case的优点是,在需要的时候可以适配拼写检查器。

建立代码风格指南

无论建立什么样的代码风格指南,一定要实现指定期望风格的.clang-format文件。虽然这对命名没有帮助,但对于开源项目来说,保持一致的风格尤为重要。

许多IDE、编辑器都支持内置的clang-format,或者可以很方便的通过加载项安装。

  • VSCode: Microsoft C/C++ extension for VS Code[2]

  • CLion: ClangFormat as alternative formatter

  • VisualStudio: ClangFormat[3]

  • Resharper++: Using Clang-Format[4]

  • Vim

    • Format your C family code[5]

    • vim-autoformat[6]

  • XCode: ClangFormat-Xcode[7]

通用C++命名约定

  • 类以大写字母开头: MyClass

  • 函数和变量以小写字母开头: myMethod

  • 常量全部大写: const double PI=3.14159265358979323

C++标准库(以及其他著名C++库,如Boost[8])使用以下指导原则:

  • 宏使用大写和下划线: INT_MAX

  • 模板参数名使用驼峰命名法: InputIterator

  • 所有其他名称都使用蛇形命名法: unordered_map

区分私有对象数据

使用m_前缀命名私有数据,以区别于公共数据,m_代表“member(成员)”数据。

区分函数参数

最重要的是保持代码库的一致性,这是一种有助于保持一致性的方式。

使用t_前缀命名函数参数,t_可以被认为是“the”,但其可以表示任意含义,关键是要将函数参数与作用域内的其他变量区分开来,同时遵循一致的命名策略。

可以为团队选择任何前缀或后缀,下面是一个例子,提出了一个有争议的建议,相关讨论见issue #11[9]


   
  1. struct Size
  2. {
  3.   int width;
  4.   int height;
  5.   Size(int t_width, int t_height) : width(t_width), height(t_height) {}
  6. };
  7. // This version might make sense for thread safety or something,
  8. // but more to the point, sometimes we need to hide data, sometimes we don't.
  9. class PrivateSize
  10. {
  11.   public:
  12.     int width() const { return m_width; }
  13.     int height() const { return m_height; }
  14.     PrivateSize(int t_width, int t_height) : m_width(t_width), m_height(t_height) {}
  15.   private:
  16.     int m_width;
  17.     int m_height;
  18. };

不要用下划线(_)作为名字的开头

_ 开头的名字有可能与编译器或标准库的保留名发生冲突: What are the rules about using an underscore in a C++ identifier?[10]

良好代码风格示例


   
  1. class MyClass
  2. {
  3. public:
  4.   MyClass(int t_data)
  5.     : m_data(t_data)
  6.   {
  7.   }
  8.   int getData() const
  9.   {
  10.     return m_data;
  11.   }
  12. private:
  13.   int m_data;
  14. };

使Out-of-Source-Directory构建

确保构建生成的文件存放在与源文件夹分离的输出文件夹中。

使用nullptr

C++11引入了nullptr表示空指针,应该用来代替0NULL来指示空指针。

注释

注释块应该使用//,而不是/* */,使用//可以更容易的在调试时注释掉代码块。


   
  1. // this function does something
  2. int myFunc()
  3. {
  4. }

要在调试期间注释掉这个函数块,可以这样做:


   
  1. /*
  2. // this function does something
  3. int myFunc()
  4. {
  5. }
  6. */

如果函数头注释使用/* */,这么做就会有冲突。

永远不要在头文件中使用using namespace

这会导致正在using的命名空间被强行拉入到包含头文件的所有文件的命名空间中,从而造成命名空间污染,并可能在导致名称冲突。在实现文件中using命名空间就足够了。

Include保护符

头文件必须包含名称清晰的include保护符,从而避免同一头文件被多次include的问题,并防止与其他项目的头文件发生冲突。


   
  1. #ifndef MYPROJECT_MYCLASS_HPP
  2. #define MYPROJECT_MYCLASS_HPP
  3. namespace MyProject {
  4.   class MyClass {
  5.   };
  6. }
  7. #endif

此外还可以考虑使用#pragma once指令,这是许多编译器的准标准,内容简短,意图明确。

代码块必须包含{}

省略{}可能会导致代码语义错误。


   
  1. // Bad Idea
  2. // This compiles and does what you want, but can lead to confusing
  3. // errors if modification are made in the future and close attention
  4. // is not paid.
  5. for (int i = 0; i < 15; ++i)
  6.   std::cout << i << std::endl;
  7. // Bad Idea
  8. // The cout is not part of the loop in this case even though it appears to be.
  9. int sum = 0;
  10. for (int i = 0; i < 15; ++i)
  11.   ++sum;
  12.   std::cout << i << std::endl;
  13. // Good Idea
  14. // It's clear which statements are part of the loop (or if block, or whatever).
  15. int sum = 0;
  16. for (int i = 0; i < 15; ++i) {
  17.   ++sum;
  18.   std::cout << i << std::endl;
  19. }

保持每行代码长度合理


   
  1. // Bad Idea
  2. // hard to follow
  3. if (x && y && myFunctionThatReturnsBool() && caseNumber3 && (15 > 12 || 2 < 3)) {
  4. }
  5. // Good Idea
  6. // Logical grouping, easier to read
  7. if (x && y && myFunctionThatReturnsBool()
  8.     && caseNumber3
  9.     && (15 > 12 || 2 < 3)) {
  10. }

许多项目和编码标准都对此制定了软规则,即每行字符应该少于80或100个,这样的代码通常更容易阅读,此外还可以把两个文件并排显示在一个屏幕上,不用小字体也能看到全部代码。

使用""表示include本地文件

...<>表示include系统文件[11]


   
  1. // Bad Idea. Requires extra -I directives to the compiler
  2. // and goes against standards.
  3. #include <string>
  4. #include <includes/MyHeader.hpp>
  5. // Worse Idea
  6. // Requires potentially even more specific -I directives and
  7. // makes code more difficult to package and distribute.
  8. #include <string>
  9. #include <MyHeader.hpp>
  10. // Good Idea
  11. // Requires no extra params and notifies the user that the file
  12. // is a local file.
  13. #include <string>
  14. #include "MyHeader.hpp"

初始化成员变量

...使用成员初始化列表。

对于POD类型,初始化列表的性能与手动初始化相同,但对于其他类型,有明显的性能提升,见下文。


   
  1. // Bad Idea
  2. class MyClass
  3. {
  4. public:
  5.   MyClass(int t_value)
  6.   {
  7.     m_value = t_value;
  8.   }
  9. private:
  10.   int m_value;
  11. };
  12. // Bad Idea
  13. // This leads to an additional constructor call for m_myOtherClass
  14. // before the assignment.
  15. class MyClass
  16. {
  17. public:
  18.   MyClass(MyOtherClass t_myOtherClass)
  19.   {
  20.     m_myOtherClass = t_myOtherClass;
  21.   }
  22. private:
  23.   MyOtherClass m_myOtherClass;
  24. };
  25. // Good Idea
  26. // There is no performance gain here but the code is cleaner.
  27. class MyClass
  28. {
  29. public:
  30.   MyClass(int t_value)
  31.     : m_value(t_value)
  32.   {
  33.   }
  34. private:
  35.   int m_value;
  36. };
  37. // Good Idea
  38. // The default constructor for m_myOtherClass is never called here, so 
  39. // there is a performance gain if MyOtherClass is not is_trivially_default_constructible. 
  40. class MyClass
  41. {
  42. public:
  43.   MyClass(MyOtherClass t_myOtherClass)
  44.     : m_myOtherClass(t_myOtherClass)
  45.   {
  46.   }
  47. private:
  48.   MyOtherClass m_myOtherClass;
  49. };

在C++11中,可以为每个成员初始化默认值(使用=或使用{})。

使用=设置默认值


   
  1. // ... //
  2. private:
  3.   int m_value = 0// allowed
  4.   unsigned m_value_2 = -1// narrowing from signed to unsigned allowed
  5. // ... //

这样可以确保不会出现构造函数“忘记”初始化成员对象的情况。

用大括号初始化默认值

用大括号初始化不允许在编译时截断数据长度。


   
  1. // Best Idea
  2. // ... //
  3. private:
  4.   int m_value{ 0 }; // allowed
  5.   unsigned m_value_2 { -1 }; // narrowing from signed to unsigned not allowed, leads to a compile time error
  6. // ... //

除非有明确的理由,否则优先使用{}初始化,而不是=

忘记初始化成员会导致未定义行为错误,而这些错误通常很难发现。

如果成员变量在初始化后不会更改,则将其标记为const


   
  1. class MyClass
  2. {
  3. public:
  4.   MyClass(int t_value)
  5.     : m_value{t_value}
  6.   {
  7.   }
  8. private:
  9.   const int m_value{0};
  10. };

由于不能给const成员变量赋值,拷贝赋值操作可能对这样的类没有意义。

总是使用命名空间

几乎没有理由需要全局命名空间中声明标识符。相反,函数和类应该存在于适当命名的命名空间中,或者存在于命名空间里的类中。放在全局命名空间中的标识符有可能与来自其他库(主要是没有命名空间的C库)的标识符发生冲突。

为标准库特性使用正确的整数类型

标准库通常使用std::size_t来处理与尺寸相关的内容,size_t的大小由实现定义。

一般来说,使用auto可以避免大部分问题。

请确保使用正确的整数类型,并与C++标准库保持一致,否则有可能在当前使用的平台上不会发出警告,但如果切换到其他平台,可能会发出警告。

注意,在对无符号数执行某些操作时,可能会导致整数下溢。例如:


   
  1. std::vector<int> v1{2,3,4,5,6,7,8,9};
  2. std::vector<int> v2{9,8,7,6,5,4,3,2,1};
  3. const auto s1 = v1.size();
  4. const auto s2 = v2.size();
  5. const auto diff = s1 - s2; // diff underflows to a very large number

使用.hpp.cpp作为文件扩展名

归根结底,这是个人喜好问题,但是.hpp和.cpp已被各种编辑器和工具广泛认可。因此,这是一个务实的选择。具体来说,Visual Studio只自动识别.cpp和.cxx为C++文件,而Vim不一定会把.cc识别为C++文件。

某个特别大的项目(OpenStudio[12])使用.hpp和.cpp表示用户生成的文件,而使用.hxx和.cxx表示工具生成的文件。两者都能被很好的识别,并且区分开来有很大的帮助。

不要混用tab和空格

某些编辑器喜欢在默认情况下使用tab和空格的混合缩进,这使得没有使用完全相同的tab缩进设置的人很难阅读代码。请配置好编辑器,确保不会发生这种情况。

不要将有副作用的代码放在assert()中

assert(registerSomeThing()); // make sure that registerSomeThing() returns true
  

上述代码在debug模式下构建时可以成功运行,但在进行release构建时会被编译器删除,从而造成debug和release构建的行为不一致,原因在于assert()是一个宏,它在release模式下展开为空。

不要害怕模板

模板可以帮助我们坚持DRY原则[13]。由于宏有不遵守命名空间等问题,因此能用模板的地方就不要用宏。

明智的使用操作符重载

运算符重载是为了支持表达性语法。比如让两个大数相加看起来像a + b,而不是a.add(b)。另一个常见的例子是std::string,通常使用string1 + string2连接两个字符串。

但是,使用过多或错误的操作符重载很容易写出可读性不强的表达式。在重载操作符时,要遵循stackoverflow文章[14]中描述的三条基本规则。

具体来说,记住以下几点:

  • 处理资源时必须重载operator=(),参见下面Rule of Zero章节。

  • 对于所有其他操作符,通常只有在需要在上下文中使用时才重载。典型的场景是用+连接事物,负号可以被认为是“真”或“假”的表达式,等等。

  • 一定要注意操作符优先级[15],尽量避免不直观的结构。

  • 除非实现数字类型或遵循特定域中可识别的语法,否则不要重载~或%这样的外部操作符。

  • 永远不要重载```operator,()```[16](逗号操作符)。

  • 处理流时使用非成员函数operator>>()operator<<()。例如,可以重载operator<<(std::ostream &, MyClass const &),从而允许将类“写入”到一个流中,例如std::coutstd::fstreamstd::stringstream,后者通常用于创建值的字符串表示。

  • 这篇文章描述了更多需要重载的常见操作符: What are the basic rules and idioms for operator overloading?[17]

更多关于自定义操作符实现细节的技巧可以参考: C++ Operator Overloading Guidelines[18]

避免隐式转换

单参数构造函数

可以在编译时应用单参数构造函数在类型之间自动转换,比如像std::string(const char *),这样的转换很方便,但通常应该避免,因为可能会增加额外的运行时开销。

相反,可以将单参数构造函数标记为explicit,从而要求显式调用。

转换操作符

与单参数构造函数类似,编译器可以调用转换操作符,同样也会引入额外开销,也应该被标记为explicit


   
  1. //bad idea
  2. struct S {
  3.   operator int() {
  4.     return 2;
  5.   }
  6. };
  7. //good idea
  8. struct S {
  9.   explicit operator int() {
  10.     return 2;
  11.   }
  12. };

考虑Rule of Zero

Rule of Zero规定,除非所构造的类具有某种新的所有权形式,否则不提供编译器可以提供的任何函数(拷贝构造函数、拷贝赋值操作符、移动构造函数、移动赋值操作符、析构函数)。

目标是让编译器提供在添加更多成员变量时自动维护的最佳版本。

这篇文章介绍了这一原则的背景,并解释了几乎可以覆盖所有情况的实现技术: C++'s Rule of Zero[19]

微信公众号:DeepNoMind

参考资料

[1]

C++ Best Practises: https://lefticus.gitbooks.io/cpp-best-practices/content/

[2]

Microsoft C/C++ extension for VS Code: https://github.com/Microsoft/vscode-cpptools

[3]

ClangFormat: https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.ClangFormat#review-details

[4]

Using Clang-Format: https://www.jetbrains.com/help/resharper/2017.2/Using_Clang_Format.html

[5]

Format your C family code: https://github.com/rhysd/vim-clang-format

[6]

vim-autoformat: https://github.com/chiel92/vim-autoformat

[7]

ClangFormat-Xcode: https://github.com/travisjeffery/ClangFormat-Xcode

[8]

Boost: http://www.boost.org/

[9]

issue #11: https://github.com/lefticus/cppbestpractices/issues/11

[10]

What are the rules about using an underscore in a C++ identifier?: https://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier

[11]

include系统文件: http://blog2.emptycrate.com/content/when-use-include-verses-include

[12]

OpenStudio: https://github.com/NREL/OpenStudio

[13]

DRY原则: http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

[14]

stackoverflow文章: http://stackoverflow.com/questions/4421706/operator-overloading/4421708#4421708

[15]

操作符优先级: http://en.cppreference.com/w/cpp/language/operator_precedence

[16]

重载operator,(): http://stackoverflow.com/questions/5602112/when-to-overload-the-comma-operator?answertab=votes#tab-top

[17]

What are the basic rules and idioms for operator overloading?: https://stackoverflow.com/questions/4421706/what-are-the-basic-rules-and-idioms-for-operator-overloading?answertab=votes#tab-top

[18]

C++ Operator Overloading Guidelines: http://courses.cms.caltech.edu/cs11/material/cpp/donnie/cpp-ops.html

[19]

C++'s Rule of Zero: http://www.nirfriedman.com/2015/06/27/cpp-rule-of-zero

- END -

点击阅读原文加入知识星球

文章来源: blog.csdn.net,作者:程序员编程指南,版权归原作者所有,如需转载,请联系作者。

原文链接:blog.csdn.net/weixin_41055260/article/details/127081575

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。