NOTICE: 这篇文章的框架条目来自《C++代码整洁之道：C++17可持续软件开发模式实践》，作者: [德] 斯提芬·罗特。书籍原名"Clean C++: Sustainable Software Development Patterns and Best Practices with C++ 17"。

编码基本原则

保持简单和直接原则(KISS)

不需要原则

避免重复原则

信息隐藏原则

高内聚原则

松耦合原则

小心优化原则

最少惊讶原则

童子军原则

C++代码整洁的基本规范

良好的命名

源代码文件名、命名空间、类、函数、模板、参数、变量、常量等等等等，都应该具有有意义且比较有表现力的名字。

名称应该自注释

• bad examples

int num;
bool flag;
std::vector<Customer> list;
Product data;

• good examples

unsigned int number_of_customer;
bool is_changed;
std::vector<Customer> customers;
Product ordered_product;

自注释的命名也不应该过长，如果变量的上下文很清楚，只需要要简短的描述性名称。

避免冗余的名称

• bad example

class Customer
{
// somde code
private:
    std::string customer_name_;
};

在Customer类中已经有足够的信息能够知道name表示customer的名字了，不必要重复，重复的话违背了"Don’t Repeat Yourself "原则.

std::string string_customer_name;

不要在变量中包含变量类型。

不要用匈牙利命名法

不要在变量前面带类型前缀，在变量里面带上类型前缀，当你更改类型后还需要更改变量名，忘记改还会误导读者，匈牙利命名法在上个世纪没有强大的IDE时可能有用，但是现在提示变量类型的功能在IDE中已经非常普遍。
另外模板类怎么可能提前指定变量类型。

避免晦涩的缩写

Car ctw;	// bad
Car car_to_wash;	// good

Polygon ply1;	// bad
Polygon first_polygon;	// good

const double GOE = 9.80665;	// bad
const double gravitation_acceleration_on_earth = 9.80665; // good

注释

不要为易懂的代码写注释

customer_index++;
Customer* customer = GetCustomerByIndex(customer_index);
CustomerAccount * account = customer->GetAccount();

像这样的代码完全不需要写注释，不要低估代码阅读者的智商。

不要用注释禁用代码

特殊情况的注释

函数

只做一件事

让函数尽可能小

函数命名

函数的参数和返回值

替换C++中的C风格代码

用string代替char*

使用标准容器而不是C风格的数组

使用C++的类型转换代替C的强制类型转换

避免使用宏

资源管理

智能指针

避免显示的使用new和delete

面向对象

类的设计原则

让类尽可能的小

单一职责原则

开闭原则

里氏替换原则

接口隔离原则

无环依赖原则

依赖倒置原则

不要和陌生人说话（迪米特法则）

避免类的静态成员

设计模式和习惯用法

依赖注入模式

Dependency Injection
将组件与其需要的服务分离，这样组件就不必知道这些服务的名称，也不必知道如何获取它们。
例如：日志记录器

常见的注入方式有构造器注入和setter注入。

Adapter模式

把一个类的接口转为期望的另一个接口，让接口不兼容的类可以适配

Strategy模式

定义一组算法，然后封装每个算法，使它们可以相互替换，策略模式允许算法独立于使用它的客户端而变化。
例如：在需要排序的地方定义许多排序算法，快排，堆排，冒泡，希尔排序等等的，在用的时候可以选择。或者在格式化输出的地方，用纯文本、xml、json格式输出文本。

Command模式

常用在client/server架构中

Command处理器模式

Composite模式

将对象组合成树结构来表示“部分-整体”的层次结构。

Observer模式

Factory模式

Facade模式

Money Class模式

特例用法