从零开始发布前端代码到服务器上_前端代码规范分析（上）

代码规范细节分析

上一篇文章，我们提到了关于代码规范的代码，还是否记得？回顾：

BriceChou：前端代码规范，看看你平时是否注意​zhuanlan.zhihu.com

接下来，我们通过代码实际来进行分析。

一、 基本规范

可以最简单的通过工具来帮我们搞定最基本的错误，以前我写代码都是手动进行去除空行，添加空格，自动添加空白行。现在随着技术改进，工具插件越来越健全，很多都需要手动啦～

1.1 代码格式化

代码格式化，我们可以通过 Visual Studio Code 安装插件 Prettier 实现，让你的前端代码变得更加好看，统一。

格式化配置文件，可以参考：https://github.com/BriceChou/pure-react-app/blob/master/.editorconfig

# EditorConfig is awesome: http://EditorConfig.org

# top-most EditorConfig file
root = true

[*.md]
trim_trailing_whitespace = false

# Unix-style newlines with a newline ending every file
[*]
# Tab 转为 空格
indent_style = space
# 默认空行距离
indent_size = 2
end_of_line = lf
charset = utf-8
# 在文件最后一行，自动插入一行空行
insert_final_newline = true
max_line_length = 100
# 去除多余的空格
trim_trailing_whitespace = true

1.2 代码书写规范

我们可以参考 Google 或者 Airbnb 的代码风格，两种你可以结合看。或者坚持选用一种都行，大同小异。都是相互借鉴，基于自身情况进行改进。我经常看到有人问，这么多代码风格我该看谁的，用哪一套啊！

答案很简单，你能把一套看完并且一直坚守它，就可以了。剩下的只是去适应改进罢了，任何风格都会进步。但是最基本的一些规则，它是不会改变的。

• JS 基础版本：https://google.github.io/styleguide/jsguide.html
• CSS/HTML 基本版本：https://google.github.io/styleguide/htmlcssguide.html
• JS(含 ES6) 进阶版本：https://github.com/airbnb/javascript
• React 进阶版本：https://github.com/airbnb/javascript/tree/master/react

笔者最初选择的是 Google 的代码风格，后面 JS 引入 ES6 写法后，我参考的是 Airbnb 的代码风格。

二、具体分析

首先，二话不说，我们先进行代码格式化。

解决最基础的问题：空格混乱，换行不正确，单双引号，文件尾部不添加空白行等等问题

2.1 import 部分

经过代码格式化后，我们看到 import 部分应该是下面这种了。

import SomeClass2 from '../tools/class2';

import otherNameClass from '../tools/othernameclass';
import { anotherNameClassMethod } from '../tools/anotherNmaeClss';
import React from 'react';

import anotherNameClass1 from '../tools/anotherNmaeClss1';
// import SomeClass from "../tools/class"
import allNameClass from '../tools/someotherclass';

接下来，我们需要手动解决一些工具无法解决的问题：

• 命名不符合要求
• 存在不需要的注释代码
• import 不需要用到的模块
• 代码强迫症患者

2.1.1 变量命名规则

这个在我们初学任何语言的时候，都会学习正确的命名规则，在这我们就参考统一的驼峰命名方式就好了，地球人都这么遵守这个规则啦～

// bad case
import otherNameClass from '../tools/othernameclass';

// good case
import OtherNameClass from '../tools/OtherNameClass';

参考：Google 命名规则 https://google.github.io/styleguide/jsguide.html#naming-rules-common-to-all-identifiers

具体翻译内容，大家可以搜搜有很多中文版本。其次，文章内容有具体的举例说明。good 就是推荐的写法，bad 就是不推荐的。很简单吧～

2.1.2 存在不需要的注释代码

我发现我们最喜欢将需要的代码进行注释，而不是直接删除，这是最大陋习～

// bad case: 不需要的代码应该直接删除
// import SomeClass from "../tools/class"

大家觉得说不定后面还需要用到，我到时候注释回来，是不是很方便？

但是，大家可以看看自己写的代码里面，往往这种被注释的代码，你会发现过了好几年了，这个注释的代码还是没有被注释回来。

为什么？功能需求变化迭代，到最后基本用不上，只能写新的逻辑。大量的注释代码，也会影响到代码阅读。（我这里说的是注释代码，不是代码注释哦～）

而且，现在大家都会用 Git 来管理代码，如果我们真的需要用到旧的代码，我们完全可以通过查看代码历史提交记录的方式来找回旧代码。

可以用下面这些方式：

# 回退某次提交，回退之前的旧代码
git revert 57ec046120e9e2c23bf6989e7fbd8ad33c5c4f77

# 通过 GitK 查看某个文件具体提交历史，比如:
gitk src/code/demo.ts

这样是不是比直接把代码注释掉更加好呢？

2.1.3 引入了不需要的模块

我们经常之前用了某个模块或者组件，后面需求或者组件更新，我们就不需要再用到这个模块，代码里面移除了，但是 import 部分却没有清除

// bad case: 不需要的模块，就不需要进行引入
import allNameClass from '../tools/someotherclass';

这样会导致我们在使用 webpack 打包时候，有可能打包了很多不需要的模块，增加文件的体积，不利于代码压缩。

2.1.4 拯救代码强迫症

我个人是比较强烈的代码强迫症患者，非常不喜欢阅读那种代码长短都没有对齐的文件。

所以只要是我写的，你只要看开头就知道是我写的了，我会把代码长短进行排列，手动的方式。

自上而下，由短到长，看着就比较舒适了。这样的代码，是不是具有比较良好的舒适感呢？

未排序前：

import SomeClass2 from '../tools/class2';

import otherNameClass from '../tools/othernameclass';
import { anotherNameClassMethod } from '../tools/anotherNmaeClss';

import React from 'react';

import anotherNameClass1 from '../tools/anotherNmaeClss1';
// import SomeClass from "../tools/class"
import allNameClass from '../tools/someotherclass';

排序后：

import React, { Component } from 'react';
import SomeClass2 from '../tools/SomeClass2';
import OtherNameClass from '../tools/OtherNameClass';
import AnotherNameClass1 from '../tools/AnotherNameClass1';

2.2 TypeScript 部分

首先，我们还是先默认格式化操作一波。看到下面的代码，还存在以下问题：

• 随意进行类型的 export 操作
• 大量使用 any 类型
• 变量命名不规范

export interface demoClassProps {
  orderId: any;
}

export interface democlassState {
  number: any;
}

export default class DemoClass extends React.Component<
  demoClassProps,
  democlassState
> {}

2.2.1 随意进行类型的 export 操作

事实上，我们再使用到 Component, 大部分开发工具及 TS 自动会检查传入的参数是否正确，根本不需要我们额外再将 PropsType 进行 export 操作。

这类检查，我们还可以在 Git commit 时引入 Husky 工具：https://github.com/typicode/husky

除了 TS 外，我们在 JS 里面也是，Class, Function, Const 等等，尽量避免不必要的 export 操作。

2.2.2 大量使用 any 类型

极其不推荐及反对，大面积使用 any 或者 unknown 的类型，为什么？

这样我们就回到了 JS 时代了，失去了使用 TS 的意义了。其实就是我们比较偷懒罢了，明明知道会返回什么数据，我们偏偏就不写，特别是面对 Object 的时候，就知道写 any

这样会导致我们代码，极其不方便后续维护，因为不确定性，导致我们代码可能出现各种问题，就回到了直接用 JS 的痛苦了。

2.2.3 变量命名不规范

TS 里面我们在进行变量命名时，最好加上它的属性，这样方便我们知道此变量是什么。

比如：

interface StateType {
  number: number;
}

enum StatusEnum {
  Failed,
  Loading,
  Success,
}

此外，TS 3.8 的版本可以支持具体的引入声明，我们在引入 Type 类型的时，我们可以这样写：

import type { DataStatusType } from '../types/api/dataStatus';

这样就更加明确变量的用途，让代码更加具有阅读性。

此次更新到这啦～ 剩下部分，我们下回分解！

---

1. 前端代码规范分析（上）
2. 前端代码规范分析（下）