谈谈编码风格与编码规范

微博上,一提到编码风格时,往往也会引起腥风血雨,比如
  • JavaScript 语句后面应该加分号吗?
  • 缩进应该用 Tab、四空格还是两空格?
  • 变量应该统一提前声明好还是就近声明?
  • 变量名应该用驼峰风格还是下划线风格?
  • 注释应该采用 JSDoc 风格还是 Markdown 风格?
  • 私有属性约定用下划线开头吗?
  • 函数最好不要超过多少行?
  • ……

这类问题不仅在程序员中普遍存在,文字工作者也常常纠结:
  • 中英文混排时,中文与英文之间应该加空格吗?
  • 中英文混排时,英文字母后面应该用全角还是半角标点符号?
  • 段落前面真有必要空两格吗?
  • 引号是否应该用 『』和「」?
  • 破折号是一杠还是两杠?
  • 例如、参考等词汇后,究竟需不需要加冒号?
  • ……

       风格

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


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

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

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


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

       规范

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


      对于 JavaScript 语言来说,通用的编码规范基本没有,有的话只有一条:要能运行。除此之外,还会有一些:
  • JavaScript 文件的编码必须是 UTF-8 。
  • JavaScript 中不能出现 URL 硬编码。
  • ……

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

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

       态度

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


      好的习惯是这样的:

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

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

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

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

       关键

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


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

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

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

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

       最后

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




来自: github.com

你可能感兴趣的:(谈谈编码风格与编码规范)