「标准」的 JS风格
2016-10-31 10:09 聂微东 阅读(8904) 评论(23) 编辑 收藏 举报首先，这份 JS风格指南已经在我司的前端团队实行半年多了；
其次，在程序员的世界里，从入行到资深都需要面对几个世界级的难题，如：
- 世界上最好的编辑器是什么？
- 是用空格还是 TAB？用空格还特么衍生出 2空格 VS 4空格。
- JS到底要不要写分号？
- ...
最后，PHP是世界上最好的语言。
一、规范VS自由
对程序员的每个个体来说，有代码规范其实不一定是好事，因为肯定会影响到写码的自由。
比如某程序员习惯用 Tab，团队引入了某规范说都要换成 Spaces，这对于 Tab党来说这不是“噩耗”么。
尤其是对于老程序员，如果习惯多年的代码风格需要改变(先且不论好坏)，确实是件很拧巴的事情。
但是对整个团队来说，有代码规范肯定是大好事。而且由于好处实在太多，比如方便管理、好维护、易阅读等等，所以我也别一条条去罗列了，大家都懂:)
如果，某套代码规范甚至代码流程，能让团队中的成员都相对满意，而且还能切实的去执行...我想说：请好好珍惜这美好的时光。
目前，各个大厂、各种开源项目都有多种 JS的写法规范。今天本文介绍的 JS 规范号称“Standard Style”，绝对是使用最广的写法之一(star 7800+)，而且有提供配套的工具、插件可以方便的使用。
二、介绍“JS Standard Style”
standardjs就是这个这个项目的名称。
对了，它的作者叫 Feross，建议程序员们去了解一下，你会知道程序员世界的“猛人”到底能有多凶残。
请仔细看看这篇 JS规范要点，The Rules：
- 2 spaces – for indentation
- Single quotes for strings – except to avoid escaping
- No unused variables – this one catches tons of bugs!
- No semicolons – It's fine. Really!
- Never start a line with (, [, or `
- This is the only gotcha with omitting semicolons – automatically checked for you!
- Space after keywords if (condition)
- Space after function name function name (arg)
- Always use === instead of == – but obj == null is allowed to check null || undefined.
- Always handle the node.js err function parameter
- Always prefix browser globals with window – except document and navigator are okay
- Prevents accidental use of poorly-named browser globals like open, length, event, and name.
- And more goodness – give standard a try today!
没错，先不管这个规范带来了多大的好处和优点，但是我标注的两个条件确实有点要命：没有分号；2空格。
有关是否有分号的讨论可以写许多篇论文了；
至于用 tab还是用空格...都可以引发程序员的圣战啦。
所以这里看看就好，想了解更多的同学，强烈建议你私下去搜索些更多资料。ps：为毛要私下搜索？请参考下图，我其实只是想为你的安全考虑:)
三、先简单用起来！
官方的 demo 是使用 npm script 来展示的。
一句话表述：先全局安装 standard这个包，然后使用 CLI是实现后续的操作和展示。
$ npm install standard --global
这种方式很适合用作 JS代码的校验审核。如下图：
但是如果想配合日常开发用上，达到自动提醒，甚至自动格式化的程度，我非常推荐配合着对应的编辑器插件来使用。
四、配合编辑器插件
我喜欢和推荐这个规范的主要原因就是 —— 不用配置！
ps：如果你有了解过 ESLint，面对那各种各样的 Configuring 和 Rules，特么有几个人能坚持去看完的，反正我是放弃了。
但是使用 standardjs，它已经把规则都定好了，所以如果你接受它的规则，那么直接无脑使用就行了。如下图：
支持 standardjs插件的编辑器还是很多的，几乎前端常用的编辑器都覆盖到了：
Sublime Text、Atom、Vim、Emacs、Brackets、Visual Studio Code、WebStorm/PhpStorm。
篇幅有限，仅介绍下在 Atom编辑器下的使用和效果吧。Atom需要安装对应的两款插件：
- linter-js-standard - Linter plugin for JavaScript Standard Style
- standard-formatter - Format file contents using JavaScript Standard Style
效果如下图：
啊~这是个美好的时代。
五：如何在项目中实现统一的代码风格
不是每个程序员都有代码洁癖，也不是每个程序员都偏执的想写好代码，更多的普通人其实只是想少折腾的把工作完成就好。
所以对于在团队内推行代码规范这种事情，顺其自然就好。
但是，使用以下这套方案可以让这套规范推行的更顺畅些。
第一步：项目中使用 ESLint，安装对应的包：
- eslint
- eslint-config-standard
- eslint-plugin-promise
- eslint-plugin-standard
第二步：编辑器安装对应插件，以 Atom举例：
- linter-js-standard
- linter
- linter-eslint
- standard-formatter
最后一步：在项目中增加的 .eslintrc，只需要一行即可
extends: standard
开发时自动格式化就这么实现了，想想是不是还有点小激动呢。
ps：希望你有颗包容的心，因为在这半年来，我们也确实遇到了一些小问题，善用 stackoverflow 和开源项目对应的 Issue，各种问题你都能找到答案。
六、小结：聊几句优、缺点
对着这套 JS规范本身，一直都在泛泛而谈，优点和缺点的论述到处散落着，我在这简单梳理下我个人理解吧。
有关优点：
- 阅读代码的心情会变好 - 工作年限越长越能理解这句话的含义，这也是我最在意的一点，谁会有好心情去读第一眼糟糕的代码；更没有人愿意去读一个几百行，但是有几套代码风格的代码。
- 不用学习麻烦的 ESLint，无配置。
- 规范中有一条“No unused variables”没有细说，但确实非常有用。未使用的变量会进行提示，方便你优化、缩减代码，甚至定位问题。
- 想一想，如果团队有新人加入，不用过于担心他的代码风格了，不管他的工作年限。
- 有套路、好维护。
有关缺点：
- 如果对“JS Standard Style”的某条规范有异议，能否去修改呢？答：不能。
- 会影响少数人自由。单方面会冒犯到其他程序员，比如 Tab党、4空格党。
- 我们全团队使用 Atom，配合着对应的插件，偶尔会有点小问题。万能的 stackoverflow 和Issue 会帮助到我们。
- 对了，别被这套规范的名称给骗了，这其实不是真正的 JS标准，真正的 JS标准现在还在讨论的没玩没了呢。
以上就是我使用这套规范的感受吧。
最后，感谢已经离职的、优秀的德森同学(阿里花名“全栈”，我就问你们怕不怕)。是他强行在我们的 Nodejs Docker项目里面加上了这套玩意，让我们不得不用上了，哈哈哈哈哈哈哈哈。
这篇文章确实有点长了，那么再长点也无所谓了吧，于是我找到了下面这幅图...
七、看图，讲一个悲伤的故事
如果你没有尴尬癌，强烈推荐你看这个图片的出处 —— 《硅谷》。
真的很多搞笑的点只有程序员才能正确 Get。
就这样，over.
