谈谈编码风格与编码规范

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

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

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

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

       风格

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

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

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

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

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

       规范

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

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

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

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

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

       态度

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

      好的习惯是这样的：

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

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

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

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

       关键

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

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

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

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

      一旦你开始能从他人的代码中，去纠结以上各种问题而不是代码风格时，你的功力经常就会大增。牛逼的程序员有个不怎么对外说的秘密：去更多地看代码，看优秀的代码。迫不得已才自己去写少量代码。

       最后

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

来自: github.com