深入 C 语言和程序运行原理
于航
PayPal 技术专家
21121 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
深入 C 语言和程序运行原理
15
15
1.0x
00:00/00:00
登录|注册

20|生产加速:C 项目需要考虑的编码规范有哪些?

遇到的问题
落实方式
团队效率和协作
基于GNU规范定制
保证软件在GNU系统上的运行
统一编码行为
非ASCII字符的UTF-8编码
ASCII字符集首选
GNU gettext库
Gnulib的使用
C标准库和POSIX库
指针和数字值转换
char 类型符号性
字节序和对齐要求
标准库函数优先
Autoconf工具使用
Unix系统间移植
命名风格和约定
局部变量命名
全局变量和函数命名
变量作用域和命名
函数声明位置
静态代码分析工具建议
编译器警告优化
显式类型标注
预处理指令注释
全局和静态变量注释
文件和函数注释
结构和枚举定义
函数定义风格
代码行长度限制
团队编码规范的制定与落实
个性化编码规范
GNU编码规范的目的
字符集
国际化
系统函数
CPU 可移植性
系统可移植性
命名
语法约定
注释
格式
思考题
总结
GNU 编码规范
C项目编码规范

该思维导图由 AI 生成,仅供参考

你好,我是于航。
在本模块前面的几讲中,我主要介绍了可以为项目编码提速的 C 标准库,以及优化 C 代码的相关技巧。而在接下来的三讲中,我将为你介绍大型 C 项目在工程化协作时需要关注的编码规范、自动化测试和结构化编译。当项目由小变大,参与人数由少变多时,这些便是我们不得不考虑的重要内容。
和一个人参与项目、写代码时的“单打独斗”相比,多人协作从理论上来看可以大幅提高生产效率。但现实情况却可能是,效率在提升的同时,代码质量下降、沟通成本变高等一系列问题也随之而来。甚至在某些情况下,团队人数的增加反而会导致项目推进效率的降低。
那为什么会出现这样的问题呢?这是因为,当参与到项目开发中的人员数量逐渐增多时,工程师们对于代码编写规范,以及项目开发生命周期(SDLC,Software Development Life Cycle)等关键事项没有形成统一的标准。而因为代码审查不通过导致的频繁返工甚至妥协,以及协作流程上的不明确与延期,使得项目的迭代周期变长,进而生产效率下降。因此,如何为团队制定统一的编码规范,并明确 SDLC 的整体流程以及其中各节点的重点注意事项,就成为了决定团队协作效率的一个重要因素。
那么,这一讲我们就来聊一聊,对于使用 C 语言编写的、需要多人协作的项目,我们应该从哪些角度来制定团队的编码规范。这里我会以 GNU C 编码规范为例来进行介绍,在此之前,我们先来看看什么是 GNU。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

C 项目编码规范是确保代码质量和团队协作效率的关键。GNU 编码规范提供了统一的格式和注释规范,包括代码格式、注释要求、命名规范、系统可移植性、CPU 可移植性、系统函数、国际化和字符集等方面。文章介绍了在 C 项目编码中需要遵循的基本习惯和规范,以及如何确保程序的可移植性和国际化。总的来说,GNU 编码规范为多人协作的 C 项目提供了统一的编码规范,有助于提高代码质量和团队协作效率。文章内容详实,适合读者快速了解 C 项目编码规范的要点和重要性。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《深入 C 语言和程序运行原理》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(5)

  • 最新
  • 精选
  • zxk
    个人主要是使用 Java 的,所在团队虽然有制定代码规范,但在实施过程中,由于时间精力问题,以及大量冗长的业务代码, Reviewer 往往没有时间精力去看的过于细致,导致代码质量逐步下降。虽然配置了一些代码检查工具,但提交者往往也不会去关注。 不知道老师的工作场景是如何落实的?有没有一些经验之谈。

    作者回复: 我的建议是,这个问题可以从几个方面来考虑,首先如果配置了代码检查工具,那最好从代码审查流程上就严格把关。甚至可以将代码审查通过作为生产发布的强制性要求。其次,要明确代码审查的目的,有一部分代码问题是可以通过 linter 等工具来自动检查和修复的,而有关代码实现方式的部分,就需要代码审查者自己严格要求了。我们一般会通过不定期组织的团队代码 review 来和团队的其他成员一起过一下历次的 pull request,这样如果有问题也可以在这个过程中发现,同时也可以一定程度上约束 reviewer 的责任和态度。虽然代码审查不会纳入考核,但谁也不希望自己 review 的 PR 漏洞百出。最后,有关代码质量,通常来说定期的重构也是少不了。当然由于不算产出,怎样平衡 ROI 要具体看了。

    2022-04-03
    1
  • ZR2021
    老师加油!!!

    作者回复: 感谢支持!

    2022-01-29
    1
  • 石天兰爱学习
    每天学一点,每天进步一点,奥力给

    作者回复: 加油!

    2022-02-23
  • Luke
    上次看了openresty的规范,觉得还不错。大家可以搜索一下。
    2022-09-22归属地:江苏
  • dog_brother
    最近正在搞代码静态检查,还在摸索中
    2022-02-28
收起评论
显示
设置
留言
5
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部