代码规范
代码规范是指程序员在编码时要遵守的规则，规范的目的就是为了让程序员编写易于阅读、可维护的代码。
试想一下，一个几十万行代码的项目，存在几种不同的代码规范，阅读起来是什么感受？连代码缩进使用空格还是 Tab 都能引发不少程序员的争论，可以说统一代码规范是非常重要的事情。
统一代码规范除了刚才所说的两点外，还有其他好处：
- 规范的代码可以促进团队合作
- 规范的代码可以降低维护成本
- 规范的代码有助于 code review（代码审查）
- 养成代码规范的习惯，有助于程序员自身的成长
当团队的成员都严格按照代码规范来写代码时，可以保证每个人的代码看起来都像是一个人写的，看别人的代码就像是在看自己的代码（代码一致性），阅读起来更加顺畅。更重要的是我们能够认识到规范的重要性，并坚持规范的开发习惯。
如何制订代码规范
代码规范一般包含了代码格式规范、变量和函数命名规范、文档注释规范等等。
代码格式
一般是指代码缩进使用空格还是 Tab、每行结尾要不要加分号、左花括号需不需要换行等等。
命名规范
命名规范一般指命名是使用驼峰式、匈牙利式还是帕斯卡式；用名词、名词组或动宾结构来命名。
const smallObject = {} // 驼峰式，首字母小写 const SmallObject = {} // 帕斯卡式，首字母大写 const strName = 'strName' // 匈牙利式，前缀表示了变量是什么。这个前缀 str 表示了是一个字符串
变量命名和函数命名的侧重点不同。
变量命名的重点是表明这个变量“是什么”，倾向于用名词命名。而函数命名的重点是表明这个函数“做什么”，倾向于用动宾结构来命名（动宾结构就是 doSomething）。
// 变量命名示例 const appleNum = 1 const sum = 10 // 函数命名示例 function formatDate() { ... } function toArray() { ... }
由于拼音同音字太多，千万不要使用拼音来命名。
文档注释
文档注释比较简单，例如单行注释使用 //，多行注释使用 /**/。
/** * * @param {number} a * @param {number} b * @return {number} */ function add(a, b) { return a + b } // 单行注释 const active = true
如果要让团队从头开始制订一份代码规范，工作量会非常大，也不现实。所以强烈建议找一份比较好的开源代码规范，在此基础上结合团队的需求作个性化修改。
下面列举一些比较出名的 JavaScript 代码规范：
CSS 代码规范也有不少，例如：
注释规范
有同学可能会听过这样一种说法：好的代码是不需要写注释的。其实这种说法有点片面。
如果你写的函数类似于以下这种：
function timestampToDate(timestamp = 0) { if (/\s/.test(timestamp)) { return timestamp } let date = new Date(timestamp) return date.toLocaleDateString().replace(/\//g, '-') + ' ' + date.toTimeString().split(' ')[0] } function objToUrlParam(obj = {}) { let param = '' for (let key in obj) { param += '&' + key + '=' + obj[key] } return param? '?' + param.substr(1) : '' }
那不写注释很正常，代码逻辑简单，变量、函数命名完全契合代码逻辑。
但在工作中还有很多业务逻辑很复杂的需求，很有可能一个函数要写很多代码，再好的函数命名、变量命名也不一定能看懂代码逻辑。并且有些业务逻辑会跨多个模块，需要跟不同模块的函数打交道。
像这种复杂的代码，还有绕来绕去的业务逻辑，如果不写注释，分分钟变成传说中的“屎山”。
我们平时强调的代码规范、项目规范、重构等等，不就是为了减少沟通，提高开发效率吗。写注释的目的也是为了让代码更加容易理解，以后出问题了，也能快速定位问题，从而解决问题。
所以我觉得这个说法应该这样理解：不是不写注释，而是不写垃圾注释。
什么是垃圾注释？罗里吧嗦一大堆讲不到重要的就是垃圾注释，注释应该着重描述“做了什么”而不是“怎么做”。
function objToUrlParam(obj = {}) { let param = '' for (let key in obj) { param += '&' + key + '=' + obj[key] } return param? '?' + param.substr(1) : '' }
例如上面这个函数，你可以这样写注释：“将对象转化为 URL 参数”。也可以这样写：“首先遍历对象，获取每一个键值对，将它们拼在一起，最后在前面补个问号，变成 URL 参数”。
第一个注释虽然描述做了什么，但对于这么简单的函数来说是不用注释的。第二个注释是垃圾注释的典型示例，描述了怎么做。
下面再看一个辣眼睛的：
public class Program { static void Main(string[] args) { /* 这个程序是用来在屏幕上 * 循环打印1百万次”I Rule!” * 每次输出一行。循环计数 * 从0开始，每次加1。 * 当计数器等于1百万时， * 循环就会停止运行*/ for (int i = 0; i < 1000000; i++) { Console.WriteLine(“I Rule!”); } } }
总的来说，注释是必要的，并且要写好注释，着重描述代码做了什么。如果还有人说不写注释，让他看看 linux 项目去，每一个文件都有注释。
如何检查代码规范
规范制订下来了，那怎么确保它被严格执行呢？目前有两个方法：
- 使用工具校验代码格式。
- 利用 code review 审查变量命名、注释。
建议使用这两个方法双管齐下，确保代码规范被严格执行。
下面让我们来看一下，如何使用工具来校验代码格式。
ESLint
ESLint最初是由Nicholas C. Zakas 于2013年6月创建的开源项目。它的目标是提供一个插件化的javascript代码检测工具。
- 下载依赖
// eslint-config-airbnb-base 使用 airbnb 代码规范 npm i -D babel-eslint eslint eslint-config-airbnb-base eslint-plugin-import
- 配置
.eslintrc文件
{ "parserOptions": { "ecmaVersion": 2019 }, "env": { "es6": true, }, "parser": "babel-eslint", "extends": "airbnb-base", }
- 在
package.json的scripts加上这行代码"lint": "eslint --ext .js test/ src/"。然后执行npm run lint即可开始验证代码。代码中的test/ src/是要进行校验的代码目录，这里指明了要检查test、src目录下的代码。
不过这样检查代码效率太低，每次都得手动检查。并且报错了还得手动修改代码。
为了改善以上缺点，我们可以使用 VSCode。使用它并加上适当的配置可以在每次保存代码的时候，自动验证代码并进行格式化，省去了动手的麻烦（下一节讲如何使用 VSCode 自动格式化代码）。
stylelint
stylelint 是一个开源的、用于检查 CSS 代码格式的开源工具。具体如何使用请看下一节。
使用 VSCode 自动格式化代码
格式化 JavaScript 代码
安装 VSCode，然后安装插件 ESLint。
选择 File -> Preference-> Settings（如果装了中文插件包应该是 文件 -> 选项 -> 设置），搜索 eslint，点击 Edit in setting.json。
将以下选项添加到配置文件
"editor.codeActionsOnSave": { "source.fixAll": true, },
配置完之后，VSCode 会根据你当前项目下的 .eslintrc 文件的规则来验证和格式化代码。
TypeScript
下载插件
npm install --save-dev typescript @typescript-eslint/parser @typescript-eslint/eslint-plugin
在 .eslintrc 配置文件，添加以下两个配置项：
module.exports = { parser: '@typescript-eslint/parser', plugins: ['@typescript-eslint'], }
在根目录下的 package.json 文件的 scripts 选项里添加以下配置项：
"scripts": { "lint": "eslint --ext .js,.ts,.tsx test/ src/", },
test/src/ 是你要校验的目录。修改完后，现在 ts 文件也可以自动格式化了。
扩展
如何格式化 HTML、Vue（或其他后缀） 文件中的 HTML 和 CSS？
这需要利用 VSCode 自带的格式化，快捷键是 shift + alt + f。假设当前 VSCode 打开的是一个 Vue 文件，按下 shift + alt + f 会提示你选择一种格式化规范。如果没提示，那就是已经有默认的格式化规范了（一般是 vetur 插件），然后 Vue 文件的所有代码都会格式化，并且格式化规则还可以自己配置。
具体规则如下图所示，可以根据自己的喜好来选择格式化规则。
因为之前已经设置过 ESlint 的格式化规则了，所以 Vue 文件只需要格式化 HTML 和 CSS 中的代码，不需要格式化 JavaScript 代码，所以我们需要禁止 vetur 格式化 JavaScript 代码：
根据上图配置完成后，回到刚才的 Vue 文件。随意打乱代码的格式，再按下 shift + alt + f ，会发现 HTML 和 CSS 中的代码已经格式化了，但是 JavaScript 的代码并没格式化。没关系，因为已经设置了 ESlint 格式化，所以只要执行保存操作，JavaScript 的代码也会自动格式化。
同理，其他类型的文件也可以这样设置格式化规范。
