ECC 中的 C 代码审查基于 cpp-review 命令的现代化 C 安全、并发与内存审查实践【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC/cpp-review是 ECCThe agent harness performance optimization system为 C 工程提供的一站式代码审查命令。它调用cpp-reviewer智能体以git diff识别改动、以clang-tidy与cppcheck做静态分析按 CRITICAL / HIGH / MEDIUM 三级严重度输出审查报告并依据无重大问题的通过标准给出 Approve / Warning / Block 结论。读完本文你将掌握在 ECC 工作流中运行 C 审查的标准姿势、三级问题的判定依据、内置自动化检查命令以及如何把cpp-coding-standards与cpp-testing技能与cpp-review组合成完整的 C 质量闭环。一、命令定位cpp-review 在 ECC 中的作用ECC 将 C 开发的质量动作拆分为可组合的命令与技能。cpp-review负责审查它与cpp-testTDD 驱动、GoogleTest 测试、cpp-build构建修复、code-review非 C 特定审查共同构成 C 工程的质量流水线。命令定义位于 commands/cpp-review.md日文版本即本任务对应的 docs/ja-JP/commands/cpp-review.md其 frontmatter 明确声明该命令覆盖内存安全memory safety、现代 C 惯用法modern C idioms、并发concurrency与安全security四个维度通过调用cpp-reviewer智能体执行。审查命令的完整执行流程为共 6 步识别 C 改动通过git diff查找变更的.cpp、.hpp、.cc、.h文件运行静态分析执行clang-tidy与cppcheck内存安全扫描检查裸new/delete、缓冲区溢出、use-after-free并发审查分析线程安全、mutex 使用、数据竞争现代 C 检查验证代码是否符合 C17/20 规范与最佳实践生成报告按严重度对问题进行分类。cpp-reviewer智能体的定义位于 agents/cpp-reviewer.md。其 frontmatter 声明了该智能体的工具集Read、Grep、Glob、Bash与默认模型sonnet并在 Prompt Defense Baseline 中要求智能体保持角色稳定、不泄露机密数据、把外部不可信内容视为不可信数据——这意味着审查行为本身受提示词防御基线约束。智能体被调用时的动作序列与命令一致先执行git diff -- *.cpp *.hpp *.cc *.hh *.cxx *.h获取最近改动再在工具可用时运行clang-tidy与cppcheck聚焦于被修改的 C 文件并立即开始审查。二、使用时机何时应该运行 /cpp-review在以下场景使用/cpp-review最为合适编写或修改 C 代码之后提交 C 改动之前作为提交前的最后一道关卡审查包含 C 代码的 Pull Request 时刚加入一个新 C 代码库、需要快速了解其质量基线时onboarding专门排查内存安全性问题leak、overflow、use-after-free时。从仓库的 rules/cpp/hooks.md 可以看到提交前的 C 变更检查链条还包括clang-format --dry-run --Werror格式检查、clang-tidy静态分析、cmake --build编译与ctest --output-on-failure测试。推荐的 CI 流水线顺序为clang-format → clang-tidy → cppcheck → cmake build → ctest带 sanitizer。cpp-review正好处于该流水线的审查收口位置。三、审查分类CRITICAL / HIGH / MEDIUM 三级问题判定cpp-review与cpp-reviewer智能体均将问题按严重度划分为三个层级下面是命令文档与智能体文档的完整合并清单。CRITICAL必须修复内存安全类无 RAII 的裸new/delete应改用std::unique_ptr或std::shared_ptr缓冲区溢出与 use-after-freeC 风格数组、无边界检查的strcpy/sprintf、悬垂指针与失效迭代器未初始化变量的读取先读后赋值空指针解引用未判空即访问内存泄漏资源未与对象生命周期绑定缺失 RAII。安全类来自 agents/cpp-reviewer.md命令注入未经校验的输入进入system()或popen()格式化字符串攻击用户输入进入printf格式化串整数溢出对不可信输入做未检查的算术运算硬编码机密源码中出现 API Key、密码等不安全转换无充分理由的reinterpret_cast。命令文档中的 CRITICAL 清单还明确包含无同步的数据竞争data races without synchronization与未初始化变量读取。HIGH应该修复Rule of Five 违规特殊成员函数不完整缺少std::lock_guard/std::scoped_lock手写lock()/unlock()无适当生命周期管理的分离线程detached threads未join()或detach()使用 C 风格 cast 而非static_cast/dynamic_cast缺乏const正确性。并发子类智能体文档补充数据竞争无同步的共享可变状态、死锁多个 mutex 以不一致顺序加锁、缺失 RAII 锁、std::thread未调用join()或detach()。代码质量子类智能体文档补充手动资源管理无 RAII、超过 50 行的大函数、超过 4 层的深嵌套、C 风格代码malloc、C 数组、用typedef而非using。MEDIUM考虑修复不必要的拷贝大对象按值传参而非const已知大小的容器缺少reserve()预分配头文件中使用using namespace std;命名空间污染重要返回值缺少[[nodiscard]]过度复杂的模板元编程。性能子类智能体文档补充缺少移动语义sink 参数未用std::move、循环内字符串拼接应使用std::ostringstream或reserve()。最佳实践子类智能体文档补充const正确性、auto使用过度/不足、头文件卫生缺少 include guard、多余 include。这些分类的判定标准与 skills/cpp-coding-standards/SKILL.md 中基于 C Core Guidelinesisocpp.github.io的规则一一对应。例如 CRITICAL 的裸 new/delete 对应 R.11避免显式调用new/delete与 R.20用unique_ptr/shared_ptr表达所有权HIGH 的 Rule of Five 对应 C.21MEDIUM 的传参拷贝对应 F.16便宜类型按值、昂贵类型按const。审查标准并非凭空而来而是有据可依的编码规范体系。四、自动化检查clang-tidy、cppcheck 与警告编译cpp-review运行时执行的自动化检查命令如下# 静态分析启用全部检查排除 llvmlibc 系列 clang-tidy --checks*,-llvmlibc-* src/*.cpp -- -stdc17 # 附加分析启用全部检查抑制系统头文件缺失告警 cppcheck --enableall --suppressmissingIncludeSystem src/ # 带警告编译-Wall -Wextra -Wpedantic cmake --build build -- -Wall -Wextra -Wpedanticcpp-reviewer智能体的诊断命令集与之对应并额外提供了构建输出的快速查看方式cmake --build build 21 | head -50这些命令与仓库规则层完全呼应rules/cpp/security.md 明确要求使用 clang-tidy 与 cppcheck 做静态分析clang-tidy --checks* src/*.cpp、cppcheck --enableall src/并要求在 CI 中启用 sanitizercmake -DCMAKE_CXX_FLAGS-fsanitizeaddress,undefined ..rules/cpp/hooks.md 则将clang-format --dry-run --Werror与clang-tidy src/*.cpp -- -stdc17列为提交钩子的一部分。要点说明clang-tidy的--checks*,-llvmlibc-*表示启用全部检查项、仅排除 LLVM libc 相关的规则该项目通常不在普通应用代码中直接使用-- -stdc17中的--之后是传递给编译器的参数确保按 C17 标准解析cppcheck --enableall打开全部检查类别包括 style、performance、portability、warning 等--suppressmissingIncludeSystem用于避免因系统头文件路径不可用产生的噪音告警cmake --build build -- -Wall -Wextra -Wpedantic在构建时追加 GCC/Clang 警告开关-Wpedantic会报告 ISO C 标准之外的扩展用法。五、审查报告示例从发现到修复的完整闭环命令文档给出了一个完整的审查会话示例展示了智能体如何组织报告。核心报告结构包括Files Reviewed审查的文件清单及变更状态如src/handler/user.cpp (modified)Static Analysis Resultsclang-tidy 与 cppcheck 的结果摘要Issues Found按严重度排列的问题每个问题给出文件:行号、问题描述、问题代码与修复代码。User: /cpp-review Agent: # C Code Review Report ## Files Reviewed - src/handler/user.cpp (modified) - src/service/auth.cpp (modified) ## Static Analysis Results ✓ clang-tidy: 2 warnings ✓ cppcheck: No issues ## Issues Found [CRITICAL] Memory Leak File: src/service/auth.cpp:45 Issue: Raw new without matching delete auto* session new Session(userId); // Memory leak! cache[userId] session; Fix: Use std::unique_ptr auto session std::make_uniqueSession(userId); cache[userId] std::move(session); [HIGH] Missing const Reference File: src/handler/user.cpp:28 Issue: Large object passed by value void processUser(User user) { // Unnecessary copy Fix: Pass by const reference void processUser(const User user) { ## Summary - CRITICAL: 1 - HIGH: 1 - MEDIUM: 0 Recommendation: FAIL: Block merge until CRITICAL issue is fixed这个示例揭示了三个值得注意的模式CRITICAL 级别的修复示范裸new导致的泄漏被修复为std::make_uniquestd::move与 skills/cpp-coding-standards/SKILL.md 中 R.11/R.20/R.21优先unique_ptr除非需要共享所有权、用make_shared创建shared_ptr完全一致HIGH 级别的修复示范大对象按值传参被改为const对应 F.16in 参数可廉价拷贝的类型按值、其余按const结论输出格式报告以 Recommendation: FAIL 形式给出明确的合并决策建议与批准标准表衔接。六、批准标准何时放行、何时拦截审查完成后cpp-review依据下表给出结论状态条件通过Approve无 CRITICAL 或 HIGH 问题警告Warning仅存在 MEDIUM 问题谨慎合并阻止Block存在 CRITICAL 或 HIGH 问题cpp-reviewer智能体的批准逻辑相同无 CRITICAL/HIGH 则 Approve仅 MEDIUM 则 Warning存在 CRITICAL/HIGH 则 Block。结合 agents/cpp-reviewer.md 中对大函数50 行与深嵌套4 层的 HIGH 级定义可以推断该审查标准刻意将可维护性与正确性并列对待任何 CRITICAL/HIGH 都会阻止合并只有纯粹的 MEDIUM 级优化建议可以带着风险合并。七、与其它命令和技能的组合完整的 C 质量闭环命令文档给出的集成建议如下先用/cpp-test确保测试通过TDD 工作流见 commands/cpp-test.mdRED → GREEN → REFACTOR先写 GoogleTest 用例再实现出现构建错误时使用/cpp-build提交前使用/cpp-review非 C 特定的关注点使用/code-review。配合的技能与规则文件包括技能skills/cpp-coding-standards/SKILL.md —— 基于 C Core Guidelines 的完整编码规范RAII 全覆盖、默认不可变、类型安全、意图表达、最小复杂度、值语义优先并提供提交前的快速检查清单无裸 new/delete、声明即初始化、默认 const、enum class、nullptr、无窄化转换、无 C 风格 cast、单参数构造函数explicit、Rule of Zero/Five、基类析构虚函数、concept 约束模板、头文件不加using namespace、RAII 锁、异常按值抛按引用捕获、\n而非std::endl、无魔数技能skills/cpp-testing/SKILL.md —— GoogleTest/GoogleMock CMake/CTest 的测试工作流、覆盖率lcov/llvm-cov、ASan/UBSan/TSan sanitizer 配置与 flaky 测试防护规则rules/cpp/security.md内存安全、缓冲区溢出、UB、静态分析、rules/cpp/patterns.mdRAII、Rule of Five/Zero、值语义、错误处理、rules/cpp/coding-style.md现代 C 特性、命名与格式化、rules/cpp/testing.mdGoogleTest/CTest、覆盖与 sanitizer、rules/cpp/hooks.md提交前检查与 CI 流水线。一个推荐的完整工作流是/cpp-test先写测试驱动实现 →cmake --build保证编译 →ctest带 sanitizer 跑测试 →clang-format保证格式 →/cpp-review做最终审查审查通过后提交。这样静态分析clang-tidy/cppcheck、动态检查sanitizer、测试覆盖与人工审查四个维度都覆盖到位。八、总结cpp-review是 ECC 面向 C 工程的质量收口命令其价值在于把内存安全、现代 C 惯用法、并发、安全四个审查维度、三级严重度分类、三类自动化检查clang-tidy、cppcheck、警告编译与明确的批准/阻止标准固化成一个可重复执行的命令并以cpp-reviewer智能体为载体与cpp-coding-standards、cpp-testing技能及rules/cpp/规则族形成完整的 C 质量保障体系。对开发者而言提交前运行/cpp-review并用报告中的 CRITICAL/HIGH 清单逐项核对是拦截内存泄漏、数据竞争与安全漏洞进入主干的最直接手段。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考