cover 尽管目前使用 cpp 的项目只有一个, 但还是有必要写一个关于 cpp 的规范.

主要参考由 Google 出品的 cppguide.

Google cppguide

做一些补充说明.

IDE

Jetbrains CLion 将是首选的 ide.

如需使用 visual studio, 请安装 Jetbrains 出品的插件 ReSharper С++

其次可以使用 sublime text + easyclangcomplete 来代替.

但除非性能不足, 否则请使用 clion, 不推荐使用除 clion 之外的任何文本编辑器, 包括且不限于 sublime text, atom, vscode.

编译工具链

由于主要在 linux 平台使用, 编译器可选 gcc 或者 clang + llvm. 其中后者的编译速度要优于 gcc 工具链, 因此推荐使用 clang + llvm, 截至目前 clang 版本最新是 6.x, 不过在各大发行版源里的依然是 5.x 版本.

ccache

ccache 是一个利用缓存来加快编译速度的工具, 在项目文件多, 需要频繁编译的情况下, 可以减少90%以上的时间. 推荐使用

cmake

cmake 是一个现代化的编译工具, 通过 CMakeList.txt 内的简介的语言来自动生成 Makefile, 比传统的 automake, autoconf 等工具简单好用多了. 因此 cpp 的项目强烈推荐使用 cmake 来管理项目.

注意, 当用 cmake 来生成库的时候, 请使用 target_include_directories 指令把头文件加入到 target 当中. 这条指令有助于其他使用的库搜索头文件.

Release & Debug

默认情况下 cmake 生成的 Makefile 将会编译 Debug 模式的二进制文件, 带有调试信息, 且不带优化, 文件大小较大. 在正式部署的时候请修改为 Release 模式, 这将开启优化, 减小文件体积

尽管在 Release 模式下编译的文件已经足够小, 但仍然可以对二进制文件执行 strip 来进一步减小文件体积. 具体问男人和谷歌

man strip  

依赖

截至目前, c/c++ 项目的依赖通常依靠发行版的包管理器, 并没有什么非常好的依赖管理工具.

对于在托管于 git 里的库, 例如 GitHub 上的库, 可以使用 git submodule 来引入依赖. 在寻找此类依赖的时候, 优先寻找由 cmake 管理的项目, 这类库可以很方便的使用 cmakeadd_subdirectory 指令来加入到当前项目中.

通常在 git 上寻找依赖时, 在使用 submodule 引入之前, 先尝试在包管理器里查找有无对应的包, 版本是否可接受. 当且仅当包管理器里没有的时候才考虑使用 submodule.

语言相关

c++ 标准

考虑到目前 c++17 标准刚出没多久, 老的编译器还不支持, 因此尽量不要使用 c++17 的标准.

同时也请尽量减少 c++14 的使用, 因为 c++14 标准在一些古老的OS上的编译器仍然不支持, 例如 CentOS 7, 尽管后者可以使用 scl 来开启较新的 编译器.

除此以外由于暂时不需要考虑移植到其他的环境, c++11 标准的使用不做限制.

auto

自 c++11 以来, auto 拥有了新的功能, 自动类型推断, 适当的使用 auto 关键字可方便代码编写.

例如

auto abc = 1;  
auto abc = 1.f;  

命名空间导入

不要使用 using namespace std;, 这将会引入大量不需要的成员, 并且有造成命名空间污染的隐患.

正确的使用方式是只导入所需要的

using std::cout;  
using std::vector;  
using std::shared_ptr;  

头文件

头文件必须包含 #define Guard, 例如

#ifndef FOO_BAR_BAZ_H_
#define FOO_BAR_BAZ_H_
...
#endif  // FOO_BAR_BAZ_H_

行长度

虽然提倡 80 字符的长度限制, 不过实际上 80 长度是不够的, 因此考虑将行长度限制为 120 的长度.

缩进

使用空格缩进, 2 空格缩进感觉太挤, 考虑使用 4 空格缩进.

扫描二维码,分享此文章

snowstar