1. 为什么需要C++代码风格指南
在C++开发中，代码风格指南(lil_tea style guide)不是简单的格式偏好，而是团队协作的基石。我经历过太多因为风格混乱导致的维护噩梦：同一个项目里混用tab和空格、匈牙利命名法和下划线命名法并存、大括号位置随机摆放...这些看似小问题在大型项目中会指数级放大维护成本。
良好的代码风格能带来三个核心价值：
- 可读性：统一风格让代码像一本书一样易读
- 可维护性：新人能快速理解代码结构
- 可扩展性：一致的接口设计降低系统复杂度
2. lil_tea核心风格原则
2.1 命名约定
变量和函数命名采用小写字母+下划线风格：
cpp复制int max_buffer_size = 1024;
void calculate_checksum();
类名和枚举使用首字母大写的驼峰式：
cpp复制class SocketHandler {
enum ErrorCode { Success, Timeout };
};
宏和常量全大写：
cpp复制#define MAX_RETRY 3
const float PI = 3.14159f;
经验：避免使用单个字符命名（循环变量除外），特别是'l'、'O'这样容易与数字混淆的字母
2.2 格式化规范
- 缩进：4个空格（禁用tab）
- 行宽：不超过100字符
- 大括号：K&R风格（左大括号不换行）
cpp复制if (condition) {
// ...
} else {
// ...
}
指针和引用声明时星号/与号紧贴类型：
cpp复制char* buffer; // 不是 char *buffer
int& ref = x;
2.3 头文件管理
使用#pragma once替代传统宏防护：
cpp复制#pragma once
// 而不是 #ifndef HEADER_H #define HEADER_H
头文件包含顺序：
- 关联的头文件（对应源文件的头文件）
- 系统头文件（<>包含）
- 第三方库头文件
- 项目内其他头文件
避坑：头文件内避免使用using namespace，防止命名空间污染
3. 现代C++特性使用规范
3.1 智能指针选择
优先使用unique_ptr，仅在需要共享所有权时使用shared_ptr：
cpp复制std::unique_ptr<Socket> create_socket();
auto logger = std::make_shared<FileLogger>();
禁用裸指针管理资源，必须用RAII封装：
cpp复制// 错误示范
void load_config() {
Config* cfg = new Config();
// 可能泄漏
}
// 正确做法
void load_config() {
auto cfg = std::make_unique<Config>();
}
3.2 移动语义应用
对大型对象实现移动构造/赋值：
cpp复制class Buffer {
public:
Buffer(Buffer&& other) noexcept;
Buffer& operator=(Buffer&& rhs) noexcept;
};
使用std::move优化传参：
cpp复制void process_data(std::vector<int>&& data);
std::vector<int> raw = get_data();
process_data(std::move(raw)); // 避免拷贝
3.3 constexpr与noexcept
尽可能标记编译期常量：
cpp复制constexpr int MAX_PACKET_SIZE = 1500;
对不抛异常的函数添加noexcept：
cpp复制size_t size() const noexcept { return length_; }
4. 工程化实践要点
4.1 单元测试规范
测试用例命名反映被测功能：
cpp复制TEST(CalculatorTest, AddTwoPositiveNumbers) {
Calculator calc;
EXPECT_EQ(calc.Add(2, 3), 5);
}
使用GTest的断言宏：
- EXPECT_*：非致命断言
- ASSERT_*：致命断言（失败即终止当前用例）
4.2 日志记录标准
采用分级日志：
cpp复制LOG(DEBUG) << "Entering function";
LOG(ERROR) << "Invalid input: " << input;
日志格式包含：
- 时间戳（ISO8601格式）
- 线程ID
- 日志级别
- 源文件位置
- 实际消息
4.3 异常处理策略
仅对真正异常情况抛异常：
cpp复制// 错误用法：用异常处理业务逻辑
try {
if (!user_exists(id)) {
throw UserNotFound();
}
} catch (...) {}
// 正确做法
if (!user_exists(id)) {
return ErrorCode::UserNotFound;
}
异常类继承自std::exception：
cpp复制class NetworkError : public std::runtime_error {
public:
explicit NetworkError(const std::string& msg)
: std::runtime_error(msg) {}
};
5. 性能敏感场景优化
5.1 热点代码优化
使用benchmark验证优化效果：
cpp复制static void BM_StringCopy(benchmark::State& state) {
std::string x = "hello";
for (auto _ : state) {
std::string copy(x);
}
}
BENCHMARK(BM_StringCopy);
避免虚函数调用热路径：
cpp复制// 改用CRTP模式
template <typename Derived>
class Base {
void foo() {
static_cast<Derived*>(this)->impl();
}
};
5.2 内存管理技巧
预分配内存减少碎片：
cpp复制std::vector<Packet> packets;
packets.reserve(MAX_PACKETS); // 避免扩容拷贝
使用内存池管理小对象：
cpp复制boost::pool<> packet_pool(sizeof(Packet));
auto* pkt = new (packet_pool.malloc()) Packet();
5.3 并发编程规范
锁的使用原则：
- 细粒度锁（保护最小必要数据）
- 避免锁嵌套
- 使用RAII锁守卫
cpp复制std::mutex mtx;
{
std::lock_guard<std::mutex> lock(mtx);
shared_data.push_back(item);
} // 自动释放
原子操作替代锁：
cpp复制std::atomic<int> counter{0};
counter.fetch_add(1, std::memory_order_relaxed);
6. 工具链集成建议
6.1 静态分析配置
clang-tidy检查项示例：
yaml复制Checks: >
-*,
clang-analyzer-*,
modernize-*,
performance-*,
readability-*
WarningsAsErrors: true
6.2 编译选项优化
CMake推荐配置：
cmake复制add_compile_options(
-Wall
-Wextra
-Werror
-pedantic
-O3
-march=native
)
6.3 代码格式化工具
.clang-format配置示例：
yaml复制BasedOnStyle: LLVM
IndentWidth: 4
TabWidth: 4
UseTab: Never
BreakBeforeBraces: Linux
AllowShortIfStatementsOnASingleLine: false
7. 代码评审关注点
7.1 必须拒绝的代码模式
- 裸new/delete（改用智能指针）
- 宏定义常量（改用constexpr）
- C风格字符串（改用std::string）
- 可变参数函数（改用变参模板）
7.2 需要特别审查的场景
- 跨线程共享数据
- 资源获取操作（文件/网络）
- 递归调用
- 第三方库接口封装
7.3 评审自动化实践
预提交钩子示例：
bash复制#!/bin/sh
clang-format -i --style=file *.cpp *.h
git add -u
持续集成流水线应包含：
- 静态检查
- 单元测试覆盖率（≥80%）
- 动态分析（ASan/TSan）
- 性能基准测试
8. 风格指南实施路线
- 渐进式采用：先在新模块应用，逐步改造旧代码
- 工具强制：通过clang-format、clang-tidy等工具自动化
- 培训机制：定期组织代码风格研讨会
- 评审强化：在PR中检查风格合规性
我在实际项目中的经验是：初期会有约20%的效率损耗，但3个月后会带来30%以上的维护效率提升。关键是要坚持在代码评审中严格执行，不能妥协。