[授权发表]也谈C语言编程风格:从程序员到工程师的蜕变
2015-04-12 16:32
218 查看
by falcon wuzhangjin@gmail.com of TinyLab.org
2014/08/17
最初发表:泰晓科技 – 聚焦嵌入式 Linux,追本溯源,见微知著!
原文链接:也谈C语言编程风格:从程序员到工程师的蜕变
评论说明:为更好地聚合大家的讨论,请到上面原文的评论区回复。
学姐
我把那个C函数的代码发你邮箱了,麻烦帮我提点修改建议,非常感谢!
看了下代码,本身是实现了一个算法,代码很漂亮,注释也到位,命名也符合“见文知意”。不知道有啥需要检查的。所以跟学姐确认了一下:
Falcon
不好意思,大概看了下好像是个算法实现,有啥需要帮忙check的么?
学姐
帮我看看代码是否规范,变量的声明啥是否符合嵌入式的风格,谢谢 ;-P
Falcon
风格方面没有特定的统一规范哦,不同的项目或者公司要求有差异,比如Linux的驱动和代码由Documentation/CodingStyle规范,而所有GNU项目有他们自己的规范,其他项目类似。而公司方面,比如华为公司有自己的风格。
如果是自己开发新项目,遵循其中某个约定就好,比如Linux的,如果是老项目,则可以考虑坚持老项目原有的规范,目标是让整个代码风格统一,方便阅读和维护。
上面基本是跟学姐交流的原文,下面我们就该问题展开深入讨论,希望为有类似困惑的同学提供一些参考。
美观
方便阅读
易于理解
方便修改和维护
方便审查
方便测试
程序效率
代码质量
方便编写
总之,就是要平衡各个方面的需求,最终让产品团队高效、快乐地生产出高质量、高效的软件,并且要确保软件在整个生命周期内利于各个阶段的活动,包括前期编写、中期评审、后期测试和长期维护。
所以编码本身其实也是一种艺术。
Linux Documentation/CodingStyle
GNU Coding Standard
Uboot Coding Style
Busybox Style Guide
而公司方面,比如华为有自己的编程规范:《华为编程规范》,当然,不同的编程语言会有不同版本的规范。
根据自己在外企、民企和社区多年的项目开发经验,做个基本小结:
如果是全新的项目,推荐直接采用Linux规范
这里的全新,意味着是一个从头开发的项目。
Linux规范是笔者体验过的最“美”的风格,没有之一。当然,诸如《C Traps & Pitfalls》等提供了很好的补充,但是其他规范如果与Linux规范有冲突,请使用Linux规范。
要研究他,请重复阅读并持续实践:Documentation/CodingStyle,最好是创造些机会给社区贡献些代码。
记得善用(不是滥用)这些辅助工具:
scripts/Lindent
scripts/checkpatch.pl (更具实践性的不成文约定)
scripts/cleanpatch
scripts/cleanfile
如果公司没有制定规范,请不要重新发明轮子,即使有需要,也最多在这个之上加些补充。不要以公司创始人或者某些技术专家的喜好作为规范。
如果项目中用到第三方的库,建议这些部分保留它们自己的规范。
如果是社区项目
请遵循社区项目本身的规范,比如上面提到的Linux,GNU toolchain,Uboot, Busybox等,请用他们自己的规范。
即使GNU编码规范再“丑陋”,如果想往这个社区提交代码,为了保持整个项目的一致性,必须符合他们的规范,因为那是他们的地盘。
如果是老项目
这个“老”可能是公司历史遗留项目或者是供应商提供的源码,在维护已有的代码时,为了方便评审,请在修改代码时,千万不要尝试去修改已有代码的风格,并且在源代码基础上新增的代码也需要遵循老代码的风格,有两个方面的关注:
保持最小粒度的文件内代码风格的一致性
让变更最小化,不要给评审带来额外的干扰,而且让Reviewer看到相对舒适的代码
当然,不排除老代码就是一坨翔,那么请按照这个步骤走,同样以Linux为例:
先备份老的代码,或者先直接提交老代码入库
用工具自动格式化,请用scripts/Lindent
然后解决自动格式化工具没有处理好的问题
之后用scripts/checkpatch.pl做一些检查
生成补丁,提交变更,发送评审
上面只是把老的代码入库了,并且确保了老代码是遵循规范的,之后再单独提交新的变更,并做相应评审。这个时候就不会把老代码风格的变更与新代码的变更搅合在一起,因此会更方便评审,提高代码入库的效率。
真正的工程师,可以在音乐、电影、写作、雕塑等之外,演绎另外一门IT的艺术,为人类创造更好体验的产品,这种产品在达成某种实用功能的基础上,能够为用户的各种感官甚至精神上提供美的感受和体验,最终,这种产品不再是简单的堆砌,而是成为各方面协调一致的艺术品。
2014/08/17
最初发表:泰晓科技 – 聚焦嵌入式 Linux,追本溯源,见微知著!
原文链接:也谈C语言编程风格:从程序员到工程师的蜕变
评论说明:为更好地聚合大家的讨论,请到上面原文的评论区回复。
前言
几个礼拜前,机械工业出版社有一朋友的学姐,在新西兰读书,发过来一段代码,希望就代码风格提供些修改建议。学姐
我把那个C函数的代码发你邮箱了,麻烦帮我提点修改建议,非常感谢!
看了下代码,本身是实现了一个算法,代码很漂亮,注释也到位,命名也符合“见文知意”。不知道有啥需要检查的。所以跟学姐确认了一下:
Falcon
不好意思,大概看了下好像是个算法实现,有啥需要帮忙check的么?
学姐
帮我看看代码是否规范,变量的声明啥是否符合嵌入式的风格,谢谢 ;-P
Falcon
风格方面没有特定的统一规范哦,不同的项目或者公司要求有差异,比如Linux的驱动和代码由Documentation/CodingStyle规范,而所有GNU项目有他们自己的规范,其他项目类似。而公司方面,比如华为公司有自己的风格。
如果是自己开发新项目,遵循其中某个约定就好,比如Linux的,如果是老项目,则可以考虑坚持老项目原有的规范,目标是让整个代码风格统一,方便阅读和维护。
上面基本是跟学姐交流的原文,下面我们就该问题展开深入讨论,希望为有类似困惑的同学提供一些参考。
编程风格的意义
深入讨论之前,首先要明确编程风格的意义所在,基本的有:美观
方便阅读
易于理解
方便修改和维护
方便审查
方便测试
程序效率
代码质量
方便编写
总之,就是要平衡各个方面的需求,最终让产品团队高效、快乐地生产出高质量、高效的软件,并且要确保软件在整个生命周期内利于各个阶段的活动,包括前期编写、中期评审、后期测试和长期维护。
所以编码本身其实也是一种艺术。
编程风格有哪些成文规范
就如同艺术流派的多样性一样,编码风格没有特定的统一规范,不同的软件项目或者企业有不同的艺术风格,这些风格成文后就变成了规范,例如:Linux Documentation/CodingStyle
GNU Coding Standard
Uboot Coding Style
Busybox Style Guide
而公司方面,比如华为有自己的编程规范:《华为编程规范》,当然,不同的编程语言会有不同版本的规范。
具体(C语言开发)时应遵循哪个规范
那开发项目时,到底应该如何遵循规范呢?根据自己在外企、民企和社区多年的项目开发经验,做个基本小结:
如果是全新的项目,推荐直接采用Linux规范
这里的全新,意味着是一个从头开发的项目。
Linux规范是笔者体验过的最“美”的风格,没有之一。当然,诸如《C Traps & Pitfalls》等提供了很好的补充,但是其他规范如果与Linux规范有冲突,请使用Linux规范。
要研究他,请重复阅读并持续实践:Documentation/CodingStyle,最好是创造些机会给社区贡献些代码。
记得善用(不是滥用)这些辅助工具:
scripts/Lindent
scripts/checkpatch.pl (更具实践性的不成文约定)
scripts/cleanpatch
scripts/cleanfile
如果公司没有制定规范,请不要重新发明轮子,即使有需要,也最多在这个之上加些补充。不要以公司创始人或者某些技术专家的喜好作为规范。
如果项目中用到第三方的库,建议这些部分保留它们自己的规范。
如果是社区项目
请遵循社区项目本身的规范,比如上面提到的Linux,GNU toolchain,Uboot, Busybox等,请用他们自己的规范。
即使GNU编码规范再“丑陋”,如果想往这个社区提交代码,为了保持整个项目的一致性,必须符合他们的规范,因为那是他们的地盘。
如果是老项目
这个“老”可能是公司历史遗留项目或者是供应商提供的源码,在维护已有的代码时,为了方便评审,请在修改代码时,千万不要尝试去修改已有代码的风格,并且在源代码基础上新增的代码也需要遵循老代码的风格,有两个方面的关注:
保持最小粒度的文件内代码风格的一致性
让变更最小化,不要给评审带来额外的干扰,而且让Reviewer看到相对舒适的代码
当然,不排除老代码就是一坨翔,那么请按照这个步骤走,同样以Linux为例:
先备份老的代码,或者先直接提交老代码入库
用工具自动格式化,请用scripts/Lindent
然后解决自动格式化工具没有处理好的问题
之后用scripts/checkpatch.pl做一些检查
生成补丁,提交变更,发送评审
上面只是把老的代码入库了,并且确保了老代码是遵循规范的,之后再单独提交新的变更,并做相应评审。这个时候就不会把老代码风格的变更与新代码的变更搅合在一起,因此会更方便评审,提高代码入库的效率。
后记
如果只是简单重复的Copy & Paste,那永远可能只是个程序员/Coder,在Coding的时候必须综合思考效率、质量、协作、体验、工程等因素,并能够很好地权衡,让各个因素达成一个美的平衡,这样的Coder才会逐步成为真正意义上的工程师。真正的工程师,可以在音乐、电影、写作、雕塑等之外,演绎另外一门IT的艺术,为人类创造更好体验的产品,这种产品在达成某种实用功能的基础上,能够为用户的各种感官甚至精神上提供美的感受和体验,最终,这种产品不再是简单的堆砌,而是成为各方面协调一致的艺术品。
相关文章推荐
- C语言编程风格(转)
- C语言的编程风格
- C++代码书写风格的一点小结(也许会对编程经验在两个月以下的程序员会有一定参考价值)
- PHP程序员的自我修炼:PHP编程风格
- VC命名规范以及初学者福音 C语言的编程风格
- c语言的编程风格
- C语言编程风格--Points on C 学习(2)
- C语言实现动态数组(以面向对象的编程风格)
- 谈谈C语言教学:应该从一开始就培养学生良好的编程风格和习惯
- 开发者是如何提升技能水平的 发表于1小时前| 770次阅读| 来源SquareSpace| 1 条评论| 作者Denis Gobo 开源程序员博客代码编程经验分享 摘要:作为一个技术开发人员,不断的学
- c语言的编程风格
- C语言的编程风格
- c语言的编程风格
- (原创)严谨的编程风格-C语言不可忽略的强制类型转换(严谨、C、类型转换)
- 【水文】也谈求职中的fizz-buzz-thing,兼谈程序员为什么不会编程
- C语言的编程风格
- C语言编程中避免不必要错误的几点编程风格建议
- 谈谈C语言教学:应该从一开始就培养学生良好的编程风格和习惯
- c语言编程风格
- c语言编程风格