WebRTC项目C++代码风格指南详解

前言

在参与WebRTC项目开发时，遵循一致的代码风格对于维护代码质量和可读性至关重要。本文将深入解析WebRTC项目的C++代码风格规范，帮助开发者快速掌握项目要求。

基础规范

WebRTC项目主要遵循Chromium C++风格指南和Google C++风格指南，当两者出现冲突时，Chromium风格指南优先。此外，本文档中的规则高于上述两个指南。

C++版本要求

WebRTC采用C++17标准，但有两点重要限制：

1. 仅允许使用Chromium未禁止的C++17特性（包括语言特性和库特性）
2. 仅允许使用同时兼容C++20的C++17特性

这种限制确保了代码在C++20模式下也能正常编译。

文件组织规范

头文件与源文件配对

.h和.cc文件应当成对出现，保持相同名称（后缀除外）、相同目录和相同构建目标中。具体规则如下：

1. path/to/foo.h中的声明应当在path/to/foo.cc中实现
2. path/to/foo.cc中的定义应当在path/to/foo.h中声明
3. 如果.cc文件内容为空，可以省略该文件，但仍需在构建目标中包含.h文件
4. 如果.h文件内容为空，可以省略该文件（常见于单元测试文件和包含main函数的文件）

这种组织方式提高了代码的可维护性，避免了构建系统中的不良实践。

代码注释规范

TODO注释

遵循Google风格指南中的TODO注释规范。当引用WebRTC的bug时，推荐使用URL格式（不包含协议部分）：

// TODO: bugs.webrtc.org/12345 - 当阻塞性问题解决后删除此临时方案

不推荐使用类似webrtc:12345的简短形式。

弃用API处理

弃用标记

使用[[deprecated]]属性标记已弃用的函数和类声明：

[[deprecated("bugs.webrtc.org/12345")]]
std::pony PonyPlz(const std::pony_spec& ps);

对于内联函数定义或类型别名，推荐使用ABSL_DEPRECATE_AND_INLINE宏：

ABSL_DEPRECATE_AND_INLINE() inline int OldFunc(int x) {
  return NewFunc(x, 0);
}
using OldTypeName ABSL_DEPRECATE_AND_INLINE() = NewTypeName;

注意事项

1. 弃用标记应放在.h文件的声明处，而非.cc文件中的定义处
2. 如需在单元测试中使用已弃用函数而不触发错误，可采用以下方案：

std::pony DEPRECATED_PonyPlz(const std::pony_spec& ps);
[[deprecated("bugs.webrtc.org/12345")]]
inline std::pony PonyPlz(const std::pony_spec& ps) {
  return DEPRECATED_PonyPlz(ps);
}

常用工具类

ArrayView使用指南

当需要传递数组值给函数时，优先使用rtc::ArrayView（不涉及所有权转移且不改变数组大小的情况）：

传统形式	推荐形式
const std::vector<T>&	ArrayView<const T>
const T* ptr, size_t num_elements	ArrayView<const T>
T* ptr, size_t num_elements	ArrayView<T>

字符串处理规范

WebRTC使用UTF-8编码的std::string。处理外部输入时需特别注意编码验证。

字符串拼接推荐使用：

• webrtc::StrJoin
• rtc::SimpleStringBuilder

不推荐使用的字符串构建工具：

• +运算符（存在性能问题）
• absl::StrCat/absl::StrAppend/absl::StrJoin（优化速度而非代码体积）
• strcat（易导致缓冲区溢出）

智能指针使用规范

推荐使用的智能指针类型：

• std::unique_ptr（单一所有权对象）
• webrtc::scoped_refptr（共享所有权对象）

禁止使用std::shared_ptr，这是Chromium风格指南明确禁止的。

现代C++特性指南

std::bind替代方案

避免使用std::bind，现代C++中lambda表达式几乎同样简洁且更安全。

std::function使用建议

允许使用std::function，但需注意：

• 适当场景优先考虑接口设计
• 当调用方不保存函数对象时，考虑使用rtc::FunctionView
• 能通过移动而非复制完成任务时，优先使用absl::AnyInvocable

前向声明规范

遵循Google C++风格指南：尽可能避免使用前向声明，直接包含所需头文件。

RTTI限制

WebRTC禁止使用dynamic_cast和RTTI（运行时类型识别），项目编译时启用了-fno-rtti标志。

替代方案：使用static_cast并自行确保类型安全。

构建系统规范

GN模板使用规范

WebRTC使用GN构建系统，库目标应优先使用rtc_library模板：

基础模板	WebRTC专用模板	使用场景说明
executable	rtc_executable	可执行文件
shared_library	rtc_shared_library	共享库
source_set	rtc_source_set	仅头文件库（其他情况用rtc_library）
static_library	rtc_static_library	需要静态库时使用
test	rtc_test	测试目标

目标可见性管理

WebRTC专用GN模板默认允许项目内所有目标依赖。建议尽可能限制可见性：

• 仅被少量目标使用时：visibility = [ ":foo", ":bar" ]
• 仅被同一BUILD.gn文件中的目标使用时：visibility = [ ":*" ]
• 允许项目外目标依赖时：visibility = [ "*" ]（仅限WebRTC原生API头文件）

条件编译规范

尽量避免使用C预处理器进行条件编译。必须使用时，应通过GN变量控制：

if (apm_debug_dump) {
  defines = [ "WEBRTC_APM_DEBUG_DUMP=1" ]
} else {
  defines = [ "WEBRTC_APM_DEBUG_DUMP=0" ]
}

代码中使用#if而非#ifdef或#if defined()：

#if WEBRTC_APM_DEBUG_DUMP
// 调试代码
#else
// 生产代码
#endif

结合-Wundef编译选项，可在符号拼写错误或未定义时产生编译警告。

其他语言规范

Java代码规范

遵循Google Java风格指南。

Objective-C/Objective-C++规范

遵循Chromium Objective-C和Objective-C++风格指南。

Python代码规范

遵循Chromium Python风格（基于PEP-8）。旧版Python脚本可能不符合当前规范，可通过添加到特定列表来忽略检查。

结语

遵循WebRTC代码风格指南不仅能提高代码质量，还能确保项目的一致性。在修改现有代码时，如果遇到不符合当前规范的代码，建议先进行清理再实现新功能。