小议前端代码规范
2015-12-29 19:03 大额_skylar 阅读(3804) 评论(5) 编辑 收藏 举报俗话说的好，无规矩不成方圆。
在团队中，代码规范的统一不仅能提高代码质量，对代码的维护者来说也是节省成本的事情。要知道在团队中，我们平常写代码不能仅仅考虑到自己的感受，在业务的更替中，往往维护者也会更替。在业务的交接过程中如何降低交接成本也是很重要的事情，因为我们不可能总是甩手的人，大家往往也是另一个业务的接替者。
因此大家经常谈到编码规范的问题，并探讨如何写出灵活，稳定，高质量和可维护的代码。长此以往也有很多同学总结了一些代码规范，例：[http://codeguide.bootcss.com/],[http://www.alloyteam.com/2012/07/google-recommends-the-html5-code-specifications/],等等。希望以此来规范大家的编码。
但效果可能并不明显。在需求紧张，快速迭代的项目中，大家可能不会也没有时间去遵守一些细节上的规范。这就使得编码规范也就成了纸上谈兵。
于是自动化的规范检查和修改的一些工具也就应运而生了。像JSLint,CSS Lint和ESLint。
这里我们来看看ESLint。
一、什么是ESLint？
ESLint是鼎鼎大名的Nicholas C. Zakas发起的一个开源项目。一个用于识别和反馈代码中模式错误的工具。
对于已有的JSLint,CSS Lint来说，ESLint向前走了几步，这也是Nicholas C.Zakas想要在ESLint中解决的几个问题：
1.单一的运行时环境；
JSHint 和 CSS Lint 都可以运行在 Rhino 和 Node.js中。听起来好像挺不错的样子。但是事实上，要想在两个环境中都良好的运行，要花的时间和测试的成本应该还是挺可观的。
2.规则的开启与禁用；
规则应该有明确的启用和禁用的规则。并且需要有语义的提示。这一点在JSHint做的并不够好。
3.文档；
明确的文档是开发者和使用者的小助手。JSLint 几乎就没有文档，当然JSHint已经改进了些，但在遇到某些问题时还是常常求助无门。所以ESLint的文档就相当的完善。
4.规则的配置；
在JSHint中，有些规则要配置true来启用，但是有些却需要配置false来启用，经常会晕乎乎吧。
5.规则的优先级别；
在JSHint中只有error，也就是说你配置了规则，便要要个遵守，因为报了个错嘛。CSS Lint中已经支持了warning，这样更加人性化，因为如果因为空格和tab的冲突而让代码error而不能提交，显得好无语。
6.编写自己的规则；
这就是可扩展性，围绕着ESLint，开发者可以根据自己的需求来开发适应自己业务的插件。
二、ESLint可以为我们做些什么？
1.开始使用ESLint
在我们的项目中使用ESLint只要三步：
1 1.npm install -g eslint; //安装 2 2.eslint --init; //初始化项目，这会让我们回答几个问题，以自动生成初始eslint文件 3 3.eslint app.js //开始lint我们的文件
然后就可以在控制台中看到我们的warnings和errors了。
当然，面对一堆错误和警告，有的可能是分号的问题，有的可能是空格和tab的问题。这对于刚刚开始使用eslint的同学真的很头疼，文件足够大的话，修空格和tab就会让人哭晕在厕所。
不要着急，通过自动fix一些问题，会减轻我们不少的工作量：
eslint app.js --fix
通过执行自动修复，可以把规则中可自动修复的规则（这里面的规则中后面括号中是fixable的）给修复掉。
自己试了下，解决了不少编码风格上的问题。
2.ESLint的配置文件
在我们刚刚init的项目的时候，可以看到通过我们回答的问题，eslint会自动生成一个配置文件。
在eslint中，支持几种格式的配置文件，包括：
1 .eslintrc.js 2 .eslintrc.yaml 3 .eslintrc.yml 4 .eslintrc.json 5 .eslintrc
当一个项目中有多个种类后缀的eslintrc文件时，也只会读取其中一种，优先级就是按照上面的顺序。
其实，我们可以在这里看到ESLint支持的所有规则。下面我们从一个简单的配置文件看下规则的配置。
这是上面我在自己的一个项目中生成的eslint文件[.eslintrc.js]：
1 module.exports = { 2 "rules": { 3 "indent": [ 4 2, 5 "tab" 6 ], 7 "quotes": [ 8 2, 9 "single" 10 ], 11 "linebreak-style": [ 12 2, 13 "unix" 14 ], 15 "semi": [ 16 2, 17 "always" 18 ], 19 // http://eslint.org/docs/rules/no-native-reassign 20 // 不允许 native 变量被重置 21 "no-native-reassign": 1, 22 // http://eslint.org/docs/rules/no-return-assign 23 // 是否允许 return 返回表达式 24 "no-return-assign": 1, 25 // http://eslint.org/docs/rules/no-constant-condition 26 "no-constant-condition": 1, 27 }, 28 "globals": { 29 "KISSY": true, 30 "$": true, 31 "require": true, 32 "module": true 33 }, 34 "env": { 35 "es6": true, 36 "browser": true 37 }, 38 "extends": "eslint:recommended", 39 "ecmaFeatures": { 40 "jsx": true, 41 "experimentalObjectRestSpread": true 42 }, 43 "plugins": [ 44 "react" 45 ] 46 };
这里一些关键配置的含义大概是这样的：
1 "extends": "eslint:recommended"
eslint有一些推荐的规则，用来捕捉一些比较通用的问题和错误，在后面括号中有recommended字样的规则。在配置文件中做上面这个配置，就说明这些推荐的规则全部开启。
1 "env": { 2 "es6": true, 3 "browser": true 4 },
这条配置用于高速eslint你的代码在那个环境中运行。每个环境带有自己一系列的预定义的全局变量。
1 "globals": { 2 "KISSY": true, 3 "$": true, 4 "require": true, 5 "module": true 6 },
用来添加在代码运行时我们允许的额外的全局变量。对全局变量进行约束。
1 "plugins": [ 2 "react" 3 ]
eslint允许使用第三方的变量，我们可以配置在这里。
1 "ecmaFeatures": { 2 "jsx": true, 3 "experimentalObjectRestSpread": true 4 },
eslint允许我们选择性的使用js语言的某些特性。可以通过ecmaFeatures来配置
三、小结
纸上谈兵的事情，总是不容易引起注意。
尽管我们可能为了项目的规范制定了一些规则希望大家遵守，但是主观意义上的约束实际上并不靠谱。
借助一些自动化的工具，集成到我们的开发环境中去，是一个不错的选择。
虽然刚刚开始的时候会有些阵痛，但长远来看还是比较有价值的。
