谈谈编码风格与编码规范

今天看了一篇文章,是关于编码风格的,想起来之前做项目的时候因为命名引起的一些问题,然后大家是如果不情愿的修改了已经写好的代码,然后最近一直写英语,对计算机的学习暂时告了一个段落,而且英语总结又无法公开,所以我推荐一下这篇博客.

­

一提到编码风格时，往往也会引起腥风血雨，比如

 
1. JavaScript      语句后面应该加分号吗？
 
1. 缩进应该用      Tab、四空格还是两空格？
 
1. 变量应该统一提前声明好还是就近声明？ 
2. 变量名应该用驼峰风格还是下划线风格？ 
3. 注释应该采用 JSDoc 风格还是 Markdown      风格？ 
4. 私有属性约定用下划线开头吗？ 
5. 函数最好不要超过多少行？ 
6. ……

这类问题不仅在程序员中普遍存在，文字工作者也常常纠结：

 
1. 中英文混排时，中文与英文之间应该加空格吗？
 
1. 中英文混排时，英文字母后面应该用全角还是半角标点符号？
 
1. 段落前面真有必要空两格吗？
 
1. 引号是否应该用 『』和「」？ 
2. 破折号是一杠还是两杠？ 
3. 例如、参考等词汇后，究竟需不需要加冒号？
 
1. ……

 

­

 

风格

 

我们日常说的编码规范，经常指的是 Style Guide，正确的翻译是编码风格。

既然是风格，就没有对错。就如现实生活中，我们每个人都有自己的穿着打扮一样。可能有些人打扮土一点，但土就土，并不影响什么。

很有意思的是，风格也没有孰优孰劣。比如郭敬明的打扮，很多人很喜欢，会为其尖叫为其疯狂。但在我看来，郭敬明的相貌让我非常讨厌，这还是男人吗？太锉啦。

别去争辩，喜欢和对错无关，风格亦无高低之别。

编码风格如此，文字排版风格也是一样。

 

规范

  

风格之外，也有规范。比如穿着打扮，光怪陆离都没问题，但在公众场合不能不穿。规范经常很少很少，但的的确确存在。

对于 JavaScript 语言来说，通用的编码规范基本没有，有的话只有一条：要能运行。除此之外，还会有一些：

 
1. JavaScript      文件的编码必须是 UTF-8 。 
2. JavaScript 中不能出现 URL 硬编码。 
3. ……

以上规范都是针对具体公司具体场景下的要求，除了以上这些规范，其他都是编码风格问题。

社会中的规范，是为了维护基本秩序和道德底线。编码规范，则是为了避免错误。

 

态度

  

程序员经常有个坏习惯：拿到别人的代码，喜欢首先按照自己的风格格式化一下。特别是用 Vim 的程序员，有些 Vim 程序员不光喜欢格式化他人的代码，还会在文件头留下作案凭证。

好的习惯是这样的：

@agentzh: 给他人的开源项目提交补丁也是一样：尽可能多地做足功课，弄清楚该项目使用的代码风格和测试集的组织，甚至是 git 提交日志的书面格式，尽量让我写的东西酷似项目作者本人写出的东西，这样可以节约对方的时间，是对他的最大尊重。

这就如我们去朋友家里做客，你可能会很不喜欢朋友家里的装修风格，但你最好不要自带颜料桶去帮朋友重新装修。道理不用多说，对他人的风格我们要懂得尊重，无论是在现实生活中，还是在写代码时。

当然，认可的规范还是得遵守。比如别在公共场合裸奔，别在一个 UTF-8 团队把文件存成 GBK 编码。

对待规范，要严格遵守。对待风格，要懂得尊重。

 

关键

  

一旦你拥有了开放的心态，一旦你开始懂得去欣赏他人的风格，你会发现世界是五彩缤纷的，你会开始越过一些表象，关注起一些真正值得关注的。

比如一个长得很丑的人，当你不再去看外表时，你会发现某些情况下丑人是会发光的，那种光十分漂亮，比很多帅哥漂亮百倍千倍。你会开始懂得生活，懂得真爱。

编码也如此。不再去纠结四空格还是两空格后，你会看到

 
1. 代码的逻辑抽象是否正确？
 
1. 代码背后的数据模型是否可以优化？
 
1. 这段代码是否应该放在这个文件里？
 
1. 这个模块的职责是否过大？
 
1. 这个设计模式是否用得太僵硬？
 
1. 某个功能点是否应该用 CSS      而不是 JS 来实现？
 
1. 这段代码是否忘了写单元测试？
 
1. ……

一旦你开始能从他人的代码中，去纠结以上各种问题而不是代码风格时，你的功力经常就会大增。牛逼的程序员有个不怎么对外说的秘密：

去更多地看代码，看优秀的代码。迫不得已才自己去写少量代码。

 

最后

  

代码如人，风格的差异很正常，彼此尊重。相爱是灵魂的碰触，别停留在表象。