编码规范集锦

oschina
 oschina
发布于 2013年04月08日
收藏 190

真的不知道我的第一篇真正的文章应该以什么为主题。我最终选择了编码规范。

编码规范是什么?

简单说——编码规范是一种…规范。通过建立起一种通用的约定和模式,所有人都遵循,以此帮助打造健壮的软件。

使用编码规范有什么好处?

有很多好处,包括(不仅限于此):

  1. 保持编码风格,注释风格一致,应用设计模式一致
  2. 新程序员,通过熟悉你们的编码规范,可以更容易、更快速的掌握你们的程序基础库。
  3. 减少代码中bug出现的可能性,因为程序员遇到各种情况时有标准可以简单的遵循,有现成的参考。
  4. 防止利用晦涩难懂的语言功能创造不良代码。例如,C++是一种语言猛兽。有些程序员也许会使用诸如模板和异常等语言功能,尽管这些不是很深奥的语言用法,但仍能产生意想不到的性能问题。
  5. 遵循业界广泛采用的编码规范更容易获得辅助工具。
  6. 更容易生成文档。例如,如果项目中的每个人都按照Doxygen格式写注释,你可以轻易的让程序为你的代码生成文档。

使用编码规范还有其它很多好处,在这里一一列出是不可能的。下面是一些被业界广泛采用的编码规范:

  1. 谷歌编码风格指导 – 包括针对各种语言的编码风格指导,比如C++,Python,ShellScript,Javascript等。我喜欢谷歌的风格指导的原因是,它给读者同时提供了这些编码风格建议的好的和不好的方面。所以请记住,这些编码规范并不是在任何场合都合适。
  2. 美国太空总署喷气推进实验室提供的一些编码规范指导,当然,他们是开发火箭和宇宙飞船的,所以,他们的指导并不是对所有人都合适,但还是非常有趣的。特别要提到,他们正在起草一个针对Java的编码规范。
  3. Linux内核编码风格 – 我很吃惊,他们使用8个tab键缩进,要知道,这可是相当宽的缩进。
  4. Perl语言编码风格指导 – 它提供了Perl程序形式上的风格指导。我最近在网上遇到了各种关于它的争论,尽管我不喜欢Perl(它有它的缺陷),我仍然为它具有惊人多的文档而印象深刻。我开始相信它是一个高质量的语言。Perl提供了各种各样的工具来生成文档,比如perlcritic
  5. GNU编码规范 – 主要是格式上的规范,也包含一些关于编程错误预防和编程一致性上的最佳实践方法。
[英文原文: Coding standards ]
本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 OSCHINA 社区 [http://www.oschina.net]
本文标题:编码规范集锦
加载中

最新评论(23

糯米饭团
糯米饭团
Linux内核编码风格 – 我很吃惊,他们使用8个tab键缩进,要知道,这可是相当宽的缩进。
t
teleport
使用8字符的tab键缩进我喜欢
a
appbean

引用来自“all_bright”的评论

"Linux Kernel’s coding style – I’m surprised they use 8 character tabs. Thats really wide indentation."
这样翻译是否更好:
他么使用占8个字符的tab缩进

:)

你应该批评的更严厉些
胃在烧
胃在烧

引用来自“流风回雪”的评论

哪来这么多规律,随心所欲,码随我动才好

+1
K6F
K6F
8个tab的缩进- -b
我土鳖

引用来自“七液”的评论

引用来自“我土鳖”的评论

引用来自“七液”的评论

引用来自“我土鳖”的评论

引用来自“七液”的评论

perl编码风格?perl本来就很难看懂好么~ -_=
多人开发最好不要使用过于复杂的设计模式-这个赞成
注释分开写-这个赞成
复杂而且特性繁多的语言(比如C++)这个支持.越简单的语言越容易发现问题,比起创造一个什么都能干的模板,比如做一个不会出错,调试成本低,最多多敲几次键盘的安全代码。

说得对,效率优化应该是开发后期的事情。过早的优化是万恶之源。

过早优化是万恶之源+1,stl等算法不过是通用算法,真的要用的话这些效率都不行(还得走动态规划呀~)

其实像那种什么万能模板一类的东西也算是过早优化——过早的开发效率优化。

+1,看这些stl代码其实也就那样,真的自己写也不会性能差到哪里去,而且自己写的更容易因地势宜的优化。
完全掌握这些模板需要很长时间,自己动手写个vector,list其实要不了多久,几个小时就足够了。
最关键的一条,过于复杂的语言特性,会造成非常大的代价,多人开发的短板效应完全可以掩盖几颗语法糖带来的好处。而且很容易产生过度设计,和过早优化。个人开发倒没什么,真的多人开发而且技术参差不齐的话还是怎么简单怎么来吧。

在做出第一个原型的时候,用STL无可厚非——程序最有价值的时刻就是它们第一次正常跑起来的时刻。
之后就最好看看有没有必要用自己的实现替代了。
all_bright
all_bright
"Linux Kernel’s coding style – I’m surprised they use 8 character tabs. Thats really wide indentation."
这样翻译是否更好:
他么使用占8个字符的tab缩进

:)
wx---每日佳选
wx---每日佳选
写着写着,就不想遵守了。
七液
七液

引用来自“我土鳖”的评论

引用来自“七液”的评论

引用来自“我土鳖”的评论

引用来自“七液”的评论

perl编码风格?perl本来就很难看懂好么~ -_=
多人开发最好不要使用过于复杂的设计模式-这个赞成
注释分开写-这个赞成
复杂而且特性繁多的语言(比如C++)这个支持.越简单的语言越容易发现问题,比起创造一个什么都能干的模板,比如做一个不会出错,调试成本低,最多多敲几次键盘的安全代码。

说得对,效率优化应该是开发后期的事情。过早的优化是万恶之源。

过早优化是万恶之源+1,stl等算法不过是通用算法,真的要用的话这些效率都不行(还得走动态规划呀~)

其实像那种什么万能模板一类的东西也算是过早优化——过早的开发效率优化。

+1,看这些stl代码其实也就那样,真的自己写也不会性能差到哪里去,而且自己写的更容易因地势宜的优化。
完全掌握这些模板需要很长时间,自己动手写个vector,list其实要不了多久,几个小时就足够了。
最关键的一条,过于复杂的语言特性,会造成非常大的代价,多人开发的短板效应完全可以掩盖几颗语法糖带来的好处。而且很容易产生过度设计,和过早优化。个人开发倒没什么,真的多人开发而且技术参差不齐的话还是怎么简单怎么来吧。
返回顶部
顶部