前一段时间咱们盘点了C语言中那些常见的坑，相信大家伙在日常的工作中都是：项目进度催催催，Bug改改改，头发掉掉掉…，好不容易写完的代码，质量却总是不尽如人意，各种隐患，各种“坑”，简直让人心力交瘁！你是不是也经常感觉，想要提升软件质量，却总是“心有余而力不足”？。今天，我就要给大家带来5个“锦囊妙计”！让你如何防患于未然，让你的代码质量“芝麻开花节节高”。
1. 编译器 Warning，一个都不能放过！
不知你是否有类似经历？某位同事嘴硬说"这些警告不影响功能，忽略就好"？其实编译器Warning绝对不是“狼来了”的故事！它是在认真地告诉你：“老铁，你的代码有点问题，虽然我能编译过，但可能会有坑哦！”现在没问题，指不定啥时候就爆发成大 Bug 了！所以，把它们当成 Bug 一样，认真对待，逐一消灭！
怎么做呢？很简单！
开启所用编译器的警告选项（例如 GCC 的 -Wall -Wextra -Werror，Clang 的 -Weverything）。现代IDE（Keil MDK, IAR Embedded Workbench, Eclipse + GCC 等）都提供了丰富的警告选项，可以根据你的需求进行配置，而且都可以方便地查看和管理 Warning 信息。善用IDE的提示功能，效率倍增！
温馨提示： 有些历史遗留的Warning可能比较难改，可以先放一放，集中精力搞定新增代码的Warning。但最终目标是零 Warning,零 Bug!(理想状态)
2.“静态分析” 黑科技加持！让 Bug 无处遁形！
搞定了编译器警告，代码质量就“万事大吉”了吗？Naive！编译器毕竟只能做一些“表面功夫”，有些隐藏得更深的bug，它就“鞭长莫及”了。这时候，就该 静态分析工具 上场了。那么静态分析工具都能干啥呢？
- 更深入的Bug检测： 能发现编译器发现不了的Bug，例如空指针解引用、内存泄漏、越界访问、除零错误、未使用变量等等。防患于未然，避免运行时踩坑！
- 代码风格检查： 可以强制执行统一的代码风格，避免团队成员代码风格迥异，提高代码可读性。强迫症福音！
- 安全漏洞扫描： 对于有安全要求的项目，静态分析工具可以扫描代码中潜在的安全漏洞，例如缓冲区溢出等等。而且，很多静态分析工具还能帮你检查代码是否符合MISRA C、AUTOSAR C++14 等编码规范，提升代码的规范性和安全性。
你是不是觉得静态分析工具都是“高大上”的商业软件，价格昂贵？其实现在有很多免费又好用的静态分析工具，下面给大家整理了国内外主流工具及特点对比（评论区分享你觉得好用的静态分析工具）
| 工具名称 | 官网 | 适用场景 | 优势 | 劣势 | 价格 |
|---|---|---|---|---|---|
| Clang Static Analyzer | https://clang-analyzer.llvm.org/ | C/C++ 项目，特别是嵌入式开发 | 基于 LLVM，集成度高，误报率低，功能强大 | 配置略复杂 | 免费开源 |
| clang-tidy | http://clang.llvm.org/extra/clang-tidy/ | C/C++ 项目，代码风格和现代 C++ 特性检查 | 代码风格检查，现代 C++ 特性检查，与 Clang 集成 | 可能需要根据项目具体情况进行配置 | 免费开源 |
| Cppcheck | http://cppcheck.sourceforge.net/ | C/C++ 项目，快速代码检查，资源受限的嵌入式系统 | 轻量级，速度快，误报率较低，易于使用 | 功能相对简单 | 免费开源 |
| PVS-Studio | https://pvs-studio.com/en/pvs-studio/ | C/C++/C# 项目，Bug 检测 | 商业级，功能强大，报告详细，易于使用，有免费版(个人和开源) | 商业版较贵 | 免费版/商业版 |
| Coverity | https://scan.coverity.com/ | 企业级大型项目，高精度代码分析 | 业界标杆，功能全面，精度高，误报率极低，支持 CI | 价格昂贵 | 订阅制，较贵 |
| Parasoft C/C++test | https://github.com/Tencent/TscanCode | 汽车/航空电子等，支持 MISRA/AUTOSAR 等规范 | 功能全面，支持多种编码规范检查, 自动化测试 | 部署复杂,价格高 | 高价 |
| CodeSonar | https://www.grammatech.com/products/codesonar | 安全性要求高的项目，如汽车电子、航空航天 | 专注于安全性分析, 深入的静态分析和污点分析 | 较复杂 | 商业版 |
| SonarQube (社区版) | https://www.sonarqube.org/ | 通用代码质量管理，支持多种语言，包括 C/C++ | 代码质量的全面分析和管理，社区版免费, 插件丰富, 支持CI/CD | 对于单一静态分析需求，可能过于庞大 | 社区版免费 |
| PRQA QA-C/++ | https://www.perforce.com/products/qac | 安全关键领域，如汽车电子、医疗器械 | 符合 MISRA、ISO 26262 等标准, 历史悠久, 行业认可度高 | 相对较老, 界面可能不够现代化 | 商业版 |
| PC-Lint/FlexeLint | https://www.vector.com/cn/zh/ | 传统嵌入式C/C++ | 规则全面，检查严格，历史悠久 | 配置较繁琐, 界面过时 | 商业版 |
| TscanCode | https://github.com/Tencent/TscanCode | C/C++、Lua等项目 | 中文支持好，上手快, 腾讯出品, 支持多种语言和编码规范 | 规则不如国际工具全面 | 开源免费 |
| Klocwork | https://www.perforce.com/products/klocwork | 企业级嵌入式系统 | 支持安全标准检查, 支持增量分析，适合大型项目 | 资源消耗大, 价格较高 | 订阅制 |
- IDE 集成插件： 很多 IDE，例如 VS Code, Eclipse, Keil MDK, IAR EWARM 等，都有静态分析插件，可以直接在 IDE 中进行静态分析，非常方便！例如：
- VS Code: 可以安装 C/C++ Extension，自带 Clang-Tidy 支持，还可以安装 SonarLint 等插件。
- Eclipse: 可以安装 CDT 插件，集成 Clang Static Analyzer 和 Cppcheck。
- Keil MDK, IAR EWARM: 可以安装相应的静态分析插件，例如 ARM Compiler toolchain 自带的 Arm Compiler Static Analysis。
使用建议：
- 循序渐进，逐步引入： 一下子用太多规则可能会让人懵逼，可以先从默认规则开始，逐步添加更严格的规则。
- 集成到CI/CD流程： 将静态分析集成到持续集成/持续交付流程中，每次代码提交都自动进行静态分析，尽早发现问题。自动化才是王道！
- 关注高优先级告警： 静态分析工具可能会报出很多告警，优先关注高优先级的告警，例如错误和潜在Bug。逐步解决，积少成多！
3. 代码复杂度，化繁为简是王道！
代码写久了，难免会遇到一些“巨无霸函数”——它们动辄几百行上千行，逻辑复杂，嵌套N层，可读性差到极点，自己看着都头疼，更别说别人维护了！“巨无霸函数”是代码质量的“毒瘤”，必须尽早“铲除”！如何找到这些“毒瘤”呢？秘密武器就是 “代码复杂度度量尺”(Code Complexity Metrics)！
如何度量代码复杂度？常用指标了解一下：
- 代码行数 (Lines of Code, LOC)：最简单粗暴的指标，代码行数越多，复杂度往往越高。
- McCabe 循环复杂度 (McCabe Cyclomatic Complexity, MCC) ：基于代码的 控制流图 计算复杂度， 分支越多，复杂度越高 。
- 严格循环复杂度 (Strict Cyclomatic Complexity, SCC) ：在MCC的基础上，考虑了 条件表达式的复杂度 ，更精细地衡量复杂度。
对于MCU项目，建议将复杂度阈值设定为：
- 函数行数<100行
- 圈复杂度<15
- 嵌套深度<4层
国内外常用复杂度分析工具推荐：
| 工具名称 | 官网 | 适用场景 | 优势 | 劣势 | 价格 |
|---|---|---|---|---|---|
| Lizard | https://github.com/terryyin/lizard | 多语言项目 (C/C++, Java, Python, C# 等)，快速复杂度分析 | 轻量级，支持多种语言，安装使用简单 (pip install lizard)，输出结果清晰，可计算 LOC、圈复杂度等指标 | 功能相对基础 | 免费开源 |
| cccc (C and C++ Code Counter) | http://sarnold.github.io/cccc/ | C/C++ 项目，详细复杂度报告 | 专门针对 C/C++，功能强大，可生成各种详细的报告，包括函数级别的复杂度信息 | 界面较为陈旧, 可能不支持最新的 C++ 标准 | 免费开源 |
| SourceMeter | https://www.sourcemeter.com/ | 商业级项目，全面的代码复杂度分析和趋势分析 | 商业级，功能非常全面，可生成各种图表和趋势分析报告，指标丰富 | 收费 | 商业版 |
| SonarQube (社区版) | https://www.sonarqube.org/ | 通用代码质量管理，也包括复杂度分析 | 代码质量的全面分析和管理平台 (包括复杂度、风格、Bug 等)，社区版免费，插件丰富，支持 CI/CD | 对于单一复杂度分析需求，可能过于庞大 | 社区版免费 |
| Source Insight | https://www.sourceinsight.com/ | 代码阅读和理解，辅助进行复杂度分析 | 强大的代码阅读和导航功能，也提供了一些简单的复杂度分析功能 | 主要功能是代码阅读，复杂度分析功能较弱 | 商业版 |
| Source Monitor | https://www.campwoodsw.com/ | Windows 平台，C/C++, C#, Java, VB.NET 等语言项目 | Windows 平台友好，图形界面直观，操作简单 | 仅限 Windows 平台 | 免费 |
| Understand | https://www.scitools.com/ | 大型项目，全面的代码分析 | 功能全面的代码分析工具，支持多种语言，提供丰富的分析指标和可视化 | 价格较高 | 商业版 |
| Visual Studio 代码度量功能 | (内置于 Visual Studio) | Visual Studio 用户，C/C++, C# 等项目 | VS 用户即插即用，方便快捷 | 功能相对 Visual Studio 的专业代码分析工具较弱 | 包含在 VS 中 |
| Eclipse Metrics 插件 | (Eclipse Marketplace 中搜索 “Metrics”) | Eclipse IDE 用户 | 适合 Eclipse IDE 用户，方便集成 | 功能依赖于具体插件 | 通常免费 |
| IDEA Metrics 工具 | (内置于 IntelliJ IDEA) | IntelliJ IDEA 用户 | IDEA 自带，方便使用 | 功能依赖于 IDEA 版本 | 包含在 IDEA 中 |
| VS Code CodeMetrics 插件 | (VS Code Marketplace 中搜索 “CodeMetrics”) | VS Code 用户 | 方便在 VS Code 中实时查看代码复杂度指标 | 功能依赖于具体插件 | 通常免费 |
| SLOCCount | https://dwheeler.com/sloccount/ | 多种语言，统计代码行 | 可估计软件项目大小和所需工作量 | 仅关注代码行数，结果可能不精确 | 免费开源 |
*如何降低代码复杂度？
- 函数职责单一化： 一个函数只做一件事！避免“万能函数”，把复杂函数拆分成多个小函数，提高代码可读性和可维护性。模块化设计YYDS!
- 减少代码分支： 合理使用设计模式、查表法等技巧，减少if/else,switch-case等分支语句的嵌套层数。代码逻辑更清晰！
- 提取公共代码： 将重复的代码提取成公共函数或模块，避免代码冗余，降低代码复杂度。DRY(Don’t Repeat Yourself)原则要牢记！
- 代码重构： 定期进行代码重构，优化代码结构，消除代码坏味道，降低代码复杂度。代码也需要定期“体检”！
- 代码审查： 代码审查是发现和降低代码复杂度最有效的方法之一！让同事帮你“把把脉”，看看你的代码是不是“太复杂”了！
- 设计模式 合理运用设计模式，可以提高代码的可读性、可维护性，降低代码复杂度。例如，策略模式、工厂模式、观察者模式等等。
4. 代码格式化，强迫症的福音！
代码风格不统一，简直是代码洁癖患者的噩梦！团队协作开发，你用Tab，他用空格；你用驼峰命名，他用下划线；你{另起一行，他{紧跟在后面；代码review的时候，光是代码风格就吵个不停，简直浪费生命！那么，如何统一代码风格呢？答案就是：“自动化代码格式化”！配置好规则，一键格式化，代码瞬间变得整整齐齐，赏心悦目！
针对不同嵌入式开发环境的格式化工具
- clang-format: LLVM 官方出品，功能强大，支持C/C++/Objective-C/Java/JavaScript/TypeScript等多种语言。配置灵活，格式化效果出色。嵌入式 C/C++ 项目首选！
- Uncrustify: 开源的代码格式化工具，支持 C, C++, C#, Java, Objective-C, Pawn, Vala 等语言。配置选项非常丰富，可以满足各种奇葩的代码风格需求。
- Astyle (Artistic Style): 开源的 C/C++/C#/Java 代码格式化工具，历史悠久，使用广泛。特点是格式化风格比较“艺术化”，代码看起来更美观(但可能有人觉得过度格式化)。
- EditorConfig: 如果你觉得代码格式化工具配置太复杂，可以使用 EditorConfig 来统一团队的代码风格。 EditorConfig 是一个简单的配置文件，可以定义缩进风格、行尾符、字符集等基本代码风格，支持多种编辑器和IDE。
IDE 集成： 很多 IDE (例如 VS Code, CLion, Source Insight 等)都内置了代码格式化功能，或者可以通过插件集成 clang-format, Uncrustify 等工具。配置好 IDE 的自动格式化功能，写代码的时候就不用操心格式问题了！
如何用好代码格式化工具？
- 团队统一代码风格规范： 在开始项目之前，团队成员一起讨论，制定统一的代码风格规范。可以参考一些流行的代码风格指南，例如 Google C++ Style Guide, LLVM Coding Standards 等。
- 选择合适的代码格式化工具： 根据项目语言、团队习惯等因素，选择合适的代码格式化工具。ClangFormat, Uncrustify, AStyle 都是不错的选择。
- 配置代码格式化工具： 根据团队的代码风格规范，配置代码格式化工具的参数。确保格式化后的代码符合团队规范。
- 集成到开发流程中： 将代码格式化工具集成到IDE 中、代码提交 Hook 中、CI/CD 流程中 。让代码格式化自动化！ 例如：
- 代码提交 Hook： 使用 Git Hooks，在代码提交前自动运行代码格式化工具，确保提交的代码都是格式化过的。
- CI/CD 流程： 在 CI/CD 流程中，加入代码格式化检查步骤，如果代码风格不符合规范， 就拒绝构建。
第五招： Code Review，集思广益！三人行，必有我师！
“代码审查？感觉好麻烦，浪费时间，还不如自己多测几遍！” 如果你是这么想的，容易陷入“当局者迷”的困境。因为再牛逼的程序员，也难免有疏忽的时候。
如何进行代码审查？
- 小步快跑： 代码审查要小批量、频繁进行 ！每次代码审查的代码量不要太大，例如每次审查几十行到一两百行 代码即可。这样可以提高审查效率，减少审查负担。
- Code Review Tool！ 使用代码审查工具，例如GitLab Merge Request, GitHub Pull Request, Gerrit, Review Board 等。这些工具可以简化代码审查流程 ，提高审查效率。
- Review Checklist： 制定一份简单的代码审查 Checklist ，例如：
- 代码逻辑是否正确？
- 是否有潜在的 Bug？
- 代码是否易读易懂？
- 代码风格是否符合规范？
- 是否有重复代码？
- 代码注释是否清晰完整？
- … 等等。
审查者可以对照 Checklist 进行审查，避免遗漏重要问题。
- 建设性反馈： 代码审查的重点是“改进代码质量” ，而不是“挑刺”或者“批斗大会”！ Reviewer 要给出建设性的反馈意见 ，指出代码中存在的问题，并给出改进建议 。作者要虚心接受 Reviewer 的意见，及时修改代码。互相尊重，共同进步 才是代码审查的“正确姿势”！记住，目标是提升代码质量，而不是证明谁比谁更牛！
- 选择合适的 Reviewer： 代码审查要选择合适的 Reviewer 。 Reviewer 最好是对代码模块比较熟悉，或者在相关领域有经验的同事 。如果团队规模较小，可以进行交叉审查 ，让不同模块的同事互相审查代码，这样可以促进知识共享，也能发现一些意想不到的问题。
- 定期回顾和改进： 代码审查流程不是一成不变的，要定期回顾代码审查的效果 ，收集团队成员的反馈意见 ，不断改进代码审查流程 ，使其更高效、更实用。就像“升级打怪”一样，代码审查流程也要不断“升级”！
- 自动化辅助： 结合静态分析工具和代码格式化工具，在 code review 之前先用工具进行初步检查，减少 review 的工作量，提高 review 效率。事半功倍，何乐而不为？
对于嵌入式团队，特别要关注：
- 中断处理函数
- 内存分配与释放
- 硬件访问逻辑
- 时序关键代码
这里推荐谷歌代码审查标准
总结：告别996，从提升代码质量开始！
今天的分享就到这里！希望对大家有所帮助。记住，“罗马不是一天建成的” 循序渐进，建议先从消除警告开始。然后拥抱自动化，可以把静态分析、代码格式化等工具集成到 CI/CD 流水线中，在代码提交的时候自动运行，有问题及时报警，防患于未然！
FAQ：常见问题
上期回答
Q1：为什么未初始化变量在有些情况下像有“默认值”？
A: 这纯属巧合！C语言并不保证未初始化的局部变量有任何默认值。之所以有时看起来像有默认值，是因为该内存位置恰好保留了之前的数据。这完全依赖于具体实现，绝对不可靠。我曾经因为依赖这种"巧合"，在产品上线后遇到了灾难性的随机崩溃问题，调试了整整一周。教训深刻！
Q2：“未定义行为”会导致程序崩溃吗？
A: 可能会，也可能不会——这就是"未定义"的本质！最危险的未定义行为是那些看起来工作正常的，它们可能在特定条件下突然失效，造成安全漏洞、数据损坏或系统不稳定。在我的嵌入式项目中，有一个未定义行为导致的bug在测试环境完全没问题，但在客户现场却导致了随机重启，最终追查到是一个未初始化指针在特定条件下被解引用。
Q3：嵌入式系统内存那么小，“栈”是不是很容易爆掉？
A: 极其重要！嵌入式系统的栈通常只有几KB甚至更少。不理解栈的工作原理，很容易导致栈溢出，这是嵌入式系统崩溃的常见原因之一。我始终记得一个教训：在一个8位MCU项目中，一个递归函数没有适当的终止条件，导致栈溢出并覆盖了关键的系统数据，结果整个设备变成了"砖头"。深入理解栈，对每一个嵌入式开发者都是必修课！
Q4：编译器优化越高越好吗？嵌入式开发应该怎么选优化等级？
A: 绝对不是！优化是把双刃剑。高级优化可以显著提升性能和减小代码体积，但也可能使调试变得困难，甚至改变含有未定义行为的代码的执行结果。在嵌入式开发中，我的经验是：开发阶段使用低优化级别（如-Og、-O0或-O1）以便调试，然后在最终产品中谨慎地尝试更高级的优化（建议使用-Os优化代码大小或-O2平衡性能与大小，同时使用-fno-strict-aliasing等选项避免激进优化导致的异常），同时进行全面测试。记住，在资源受限的嵌入式系统中，代码正确性和可靠性通常比极致性能更重要。
Q5：有没有什么“葵花宝典”，可以避免代码中出现“未定义行为”？
A: 实践经验：
- 始终初始化所有变量，即使是临时变量
- 使用静态代码分析工具（如cppcheck或clang-tidy）
- 开启所有相关的编译器警告（-Wall -Wextra -Werror）并确保零警告编译
- 进行代码审核，特别关注指针操作和内存管理
- 遵循安全编码标准（如MISRA C）
- 对代码进行单元测试和边界测试
- 持续学习C语言的陷阱和未定义行为
本期问题
1.对于资源受限的小型嵌入式项目，静态分析会不会带来太大开销？
2.国产MCU（如GD32、CH32等）开发环境如何配置这些工具？
3.团队成员不愿意改变既有编码习惯怎么办？
4.如何在紧张的项目进度中挤出时间来实施这些流程？
5.RTOS项目与裸机项目在实施这些流程时有什么不同？
温馨提示： 本文提到的工具和方法，仅供参考。实际应用中，还需要根据项目和团队的具体情况进行调整和选择。如有任何疑问，欢迎在评论区留言讨论。
【订阅公众号获取更多】
公众号名称：初探单片机
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
