关于程序员:C最佳实践-4-可维护性

36次阅读

共计 1168 个字符,预计需要花费 3 分钟才能阅读完成。

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

可维护性

防止应用编译宏

宏在编译之前被预处理器所替换,从而使得调试十分艰难,因为调试器无奈晓得源代码来自哪里。

// Bad Idea
#define PI 3.14159;

// Good Idea
namespace my_project {
  class Constants {
  public:
    // if the above macro would be expanded, then the following line would be:
    //   static const double 3.14159 = 3.14159;
    // which leads to a compile-time error. Sometimes such errors are hard to understand.
    static constexpr double PI = 3.14159;
  };
}

防止应用布尔值作为函数参数

在浏览代码时,布尔值无奈提供任何额定含意。能够创立一个名称更有意义的独立函数,或者传递含意更明确的枚举值。

参考 http://mortoray.com/2015/06/15/get-rid-of-those-boolean-funct… 理解更多信息。

防止应用裸循环

理解和了解现有 C ++ 规范算法,并付诸实践。

  • 参考 cppreference
  • 观看 C ++ Seasoning

将对 [] 的调用看作是一种潜在的代码坏滋味,表明没有在须要的中央应用适合的算法。

永远不要应用有副作用的assert

// Bad Idea
assert(set_value(something));

// Better Idea
[[maybe_unused]] const auto success = set_value(something);
assert(success);

在 release 版本中 assert() 将会被删除,从而造成 set_value 无奈被调用。

尽管第二个版本更丑,但总比第一个谬误版本好一点。

正确应用“override”和“final”

这些关键字使其余开发人员能够分明晓得虚函数能够被如何应用,如果虚函数的签名产生了变动,就能够捕捉潜在谬误,并有可能向编译器提醒能够执行哪些优化(参考: How does the compiler benefit from C++’s new final keyword?)。

你好,我是俞凡,在 Motorola 做过研发,当初在 Mavenir 做技术工作,对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓重的趣味,平时喜爱浏览、思考,置信继续学习、一生成长,欢送一起交流学习。\
微信公众号:DeepNoMind

本文由 mdnice 多平台公布

正文完
 0