编码风格不是编码规范
2016-08-01 16:38
204 查看
我并不认为程序员是一个情绪特别丰富的群体。但有一些事情却能很容易刺激程序员的神经,那就是代码格式和布局。如果看到一个函数的括弧在同一行上没有闭合,我的眼睛会喷血。如果看到有人没有恰好的在两个函数间留一空行,我的小腿会抽筋。但重点在这里——除非是在家里开发自己的业余爱好软件,我的这些个人喜好其实是无关紧要的。同样,作为一个团队中的一员,你的个人编程喜好也应该放到一边。
编码风格很容易会和编码规范混为一谈,因为这两个词经常会被人换着使用。我认为,编码规范同时包括了编码风格和其它规范,不仅仅指代码格式。例如,像“返回成功/失败的函数应该用一个整数作为返回值”,这样的规则不属于编码风格。在这篇文章中,编码风格简单的指一个描述如何格式化代码的说明。编码风格中的规则通常会涉及到下面这些主题:
缩进
空格使用
Tab使用
注释
命名习惯
代码行长度
语言特点风格,例如是否使用可有可无的分号
编码风格都是为特定的编程语言制定的,可以把它们看作“我们共同的约定”。如果在你的公司里,在你在时,在这些事情正在制定完成,你可以提出你的喜好,那你是幸运。但通常情况是,一种编码风格在其生命期里看着无数的程序员来了又走了。在我的眼里,遵守编码风格有下面三个主要好处:
相反,如果在一个大型的软件项目中,每个程序员都使用自己的编码风格,最终会引起一场维护版图的战争,就像动物世界里我们的这些朋友:
气味记号(也称喷洒尿液或领土记号)是动物标记自己领土范围的一种行为。通常是通过留下具有强烈气味的物质来完成,很多时候是通过在领土中突出的物体上小便。-维基百科
个人编码风格就像是狗撒尿,留下自己的势力记号。他们在代码中留下自己的符号,在程序员之间创造壁垒。
你不需要喜欢这种编码风格。如果你不喜欢里面的某条规定,那就骂几句这个文档,只向文档发脾气,就像人类迁怒于上帝。然后还是按照约定做事。这样做更具有建设性,比无休无止的吵论这些不重要的事情好的多。
有了一套编码风格并不一定会给你带来好处——除非大家都遵守。有些时候,你并不一定需要手工去调整代码。很多的程序编程器,例如Eclipse,能配置帮你格式化代码,使其符合编码风格。即使你的编辑器没有这种功能,很多其它工具也能够自动按照某种风格格式化一个文件。在我们的团队中,我们使用 indent 和 uncrustify 工具。我还听说过一些其它好东西,比如ReSharper。那些不能被自动实施的规则,例如命名习惯,可以在代码审查的过程中落实。
编码风格很容易会和编码规范混为一谈,因为这两个词经常会被人换着使用。我认为,编码规范同时包括了编码风格和其它规范,不仅仅指代码格式。例如,像“返回成功/失败的函数应该用一个整数作为返回值”,这样的规则不属于编码风格。在这篇文章中,编码风格简单的指一个描述如何格式化代码的说明。编码风格中的规则通常会涉及到下面这些主题:
缩进
空格使用
Tab使用
注释
命名习惯
代码行长度
语言特点风格,例如是否使用可有可无的分号
编码风格都是为特定的编程语言制定的,可以把它们看作“我们共同的约定”。如果在你的公司里,在你在时,在这些事情正在制定完成,你可以提出你的喜好,那你是幸运。但通常情况是,一种编码风格在其生命期里看着无数的程序员来了又走了。在我的眼里,遵守编码风格有下面三个主要好处:
1. 遵守编码风格使代码更容易维护
今天由这个程序员实现的软件,明天可能需要另外一个程序员维护。如果所有代码中大家使用同一种编码风格,这另外一个程序员快速的扫一眼陌生的代码,就能根据大家约定的编程习惯,推断出代码的作用。如果编码风格中指明常量应该全用大写字母表示,那么,当看到一个全是大写字母的变量时,你就能推断出它是常量。同样的,如果编码风格中规定包的引入要有顺序,那你立刻就能知道去哪里找这些包。这使得代码很容易维护。2. 编码风格使形成代码集体所有制
代码集体所有制意味着全体程序员要负责所有代码。集体所有制的作用很大,它能有效的增大巴士因子——一个项目能承受多少个程序员被车撞了而不影响项目的正常进行。在整个代码库中坚持延用一种常用的编码风格,所以程序员都能更容易的理解、维护。相反,如果在一个大型的软件项目中,每个程序员都使用自己的编码风格,最终会引起一场维护版图的战争,就像动物世界里我们的这些朋友:
气味记号(也称喷洒尿液或领土记号)是动物标记自己领土范围的一种行为。通常是通过留下具有强烈气味的物质来完成,很多时候是通过在领土中突出的物体上小便。-维基百科
个人编码风格就像是狗撒尿,留下自己的势力记号。他们在代码中留下自己的符号,在程序员之间创造壁垒。
3. 编码风格能消除那些长久的纷争
每个程序员都对编码风格有强烈的自我认同。这种感觉深植于每个人的自负中,每当和同事遇到是否应该在关键词周围使用空格时,这种讨论很容易升级而僵持不下。但是,静下来想想——这真的无所谓。不管是不是在关键词周围使用了空格,只要能达成一致,大家都能从中获得易维护和集体所有制的好处。在这种情况中,闭着眼睛,遵循一种编码风格就行了。你不需要喜欢这种编码风格。如果你不喜欢里面的某条规定,那就骂几句这个文档,只向文档发脾气,就像人类迁怒于上帝。然后还是按照约定做事。这样做更具有建设性,比无休无止的吵论这些不重要的事情好的多。
有了一套编码风格并不一定会给你带来好处——除非大家都遵守。有些时候,你并不一定需要手工去调整代码。很多的程序编程器,例如Eclipse,能配置帮你格式化代码,使其符合编码风格。即使你的编辑器没有这种功能,很多其它工具也能够自动按照某种风格格式化一个文件。在我们的团队中,我们使用 indent 和 uncrustify 工具。我还听说过一些其它好东西,比如ReSharper。那些不能被自动实施的规则,例如命名习惯,可以在代码审查的过程中落实。
相关文章推荐
- 编码风格不是编码规范
- 编码风格不是编码规范
- 编码风格不是编码规范
- Android 编码规范 | 代码风格指南
- Android 编码规范 | 代码风格指南
- Android开源项目-编码风格规范-Code Style Guidelines for Contributors[原创译文]
- 为什么要有编码风格规范?
- [译]Google的Java编程风格指南(Java编码规范)
- Objective-C编码风格规范
- PHP团队 编码规范 & 代码样式风格规范
- 前端编码风格规范之 HTML 规范
- Android开源项目-编码风格规范-Code Style Guidelines for Contributors
- Android 编码规范及代码风格
- 一步一步学Python(1) 基本逻辑控制举例和编码风格规范
- 淘宝JavaScript 编码风格规范
- JavaScript 风格指南/编码规范(Airbnb公司版)
- PHP团队 编码规范 & 代码样式风格规范
- PHP 编码风格规范指南
- Code Style工具规范编码风格
- 前端编码风格规范之 JavaScript 规范