前端代码规范

shjwkbac
224 阅读6分钟

前言

代码规范的重要性在软件开发中是不可忽视的，以下是一些关于代码规范重要性的原因：

  1. 提升代码质量：规范化的代码有助于提高代码质量。通过定义一致的代码风格和最佳实践，可以减少代码错误和潜在的问题。代码规范使得代码更易于理解、维护和扩展，从而提高代码的可读性和可维护性。
  2. 提升团队协作效率：在一个项目中，可能有多个开发人员共同参与。通过遵循相同的代码规范，可以使团队成员之间的代码交流更加顺畅。共享一个共同的规范标准可以减少对代码意图的解读差异，并降低团队成员之间的沟通成本。
  3. 降低维护成本：在软件开发的整个生命周期中，维护代码占据了很大的时间和资源。遵循代码规范可以使代码更易于理解，并减少修改和维护代码所需的时间和工作量。规范化的代码更容易进行调试、重构和修复bug。
  4. 提高代码可靠性：代码规范可以帮助发现并预防一些常见的代码错误。通过要求一致的命名约定、避免魔法数字、添加必要的注释等，可以减少潜在的错误和逻辑问题。这有助于提高代码的稳定性和可靠性。
  5. 提升代码的可读性和可维护性：良好的代码规范使代码更易于阅读和理解。清晰的命名约定、适当的缩进和注释等，使得其他开发人员可以更快地理解代码的意图和功能。这有助于减少开发人员之间的学习曲线，提高新成员快速上手的能力。

综上所述，代码规范对于保证代码质量、提高效率和降低维护成本至关重要。它可以促进良好的团队协作、减少错误和问题，并为项目的稳定性和可持续性打下坚实的基础。

集成editorconfig配置

EditorConfig 有助于为不同 IDE 编辑器上处理同一项目的多个开发人员维护一致的编码风格。

1.在项目根目录中创建一个名为.editorconfig的文件，在该文件中定义你希望遵循的编辑器配置规则，例如缩进大小、换行符、文件编码等。

# http://editorconfig.org

root = true

[*] # 表示所有文件适用
charset = utf-8 # 设置文件字符集为 utf-8
indent_style = space # 缩进风格（tab | space）
indent_size = 2 # 缩进大小
end_of_line = lf # 控制换行类型(lf | cr | crlf)
trim_trailing_whitespace = true # 去除行尾的任意空白字符
insert_final_newline = true # 始终在文件末尾插入一个新行

[*.md] # 表示仅 md 文件适用以下规则
max_line_length = off
trim_trailing_whitespace = false
  1. VSCode需要安装一个插件：EditorConfig for VS Code
image-20230811190016223

使用prettier工具

Prettier 是一款强大的代码格式化工具，支持 JavaScript、TypeScript、CSS、SCSS、Less、JSX、Angular、Vue、GraphQL、JSON、Markdown 等语言，基本上前端能用到的文件格式它都可以搞定，是当下最流行的代码格式化工具。

1.安装prettier

npm install prettier -D

2.配置.prettierrc.json文件：

  • useTabs：使用tab缩进还是空格缩进，选择false；
  • tabWidth：tab是空格的情况下，是几个空格，选择2个；
  • printWidth：当行字符的长度，推荐80，也有人喜欢100或者120；
  • singleQuote：使用单引号还是双引号，选择true，使用单引号；
  • trailingComma：在多行输入的尾逗号是否添加，设置为 none，比如对象类型的最后一个属性后面是否加一个，；
  • semi：语句末尾是否要加分号，默认值true，选择false表示不加；
{
  "useTabs": false,
  "tabWidth": 2,
  "printWidth": 80,
  "singleQuote": true,
  "trailingComma": "none",
  "semi": false
}

3.创建.prettierignore忽略文件

/dist/*
.local
.output.js
/node_modules/**

**/*.svg
**/*.sh

/public/*

4.VSCode需要安装 Prettier - Code formatter 插件

image-20230811191213613

5.VSCod中的配置

  • settings =>format on save => 勾选上
  • settings => editor default format => 选择 prettier

6.测试prettier是否生效

  • 测试一：在代码中保存代码；
  • 测试二：配置一次性修改的命令；

在package.json中配置一个scripts：

    "prettier": "prettier --write ."

使用ESLint检测

1.在项目根目录下，通过命令行工具安装ESLint。

npm install eslint -D

2.VSCode需要安装ESLint插件： image-20230811191039210

3.解决eslint和prettier冲突的问题：

安装插件：（vue在创建项目时，如果选择prettier，那么这两个插件会自动安装）

npm install eslint-plugin-prettier eslint-config-prettier -D

添加prettier插件：

  extends: [
    "plugin:vue/vue3-essential",
    "eslint:recommended",
    "@vue/typescript/recommended",
    "@vue/prettier",
    "@vue/prettier/@typescript-eslint",
    'plugin:prettier/recommended'
  ],

4.VSCode中eslint的配置

  "eslint.lintTask.enable": true,
  "eslint.alwaysShowStatus": true,
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    "typescript",
    "typescriptreact"
  ],
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },

git Husky和eslint

虽然我们已经要求项目使用eslint了，但是不能保证组员提交代码之前都将eslint中的问题解决掉了：

  • 也就是我们希望保证代码仓库中的代码都是符合eslint规范的；

  • 那么我们需要在组员执行 git commit 命令的时候对其进行校验，如果不符合eslint规范，那么自动通过规范进行修复；

那么如何做到这一点呢？可以通过Husky工具：

  • husky是一个git hook工具，可以帮助我们触发git提交的各个阶段：pre-commit、commit-msg、pre-push

如何使用husky呢？

1.安装husky相关的依赖:

npx husky-init && npm install

2.在 .husky 文件夹下 修改pre-commit文件内容

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npm run lint

这个时候我们执行git commit的时候会自动对代码进行lint校验。

git commit规范

commit提交风格

通常我们的git commit会按照统一的风格来提交，这样可以快速定位每次提交的内容，方便之后对版本进行控制。

但是如果每次手动来编写这些是比较麻烦的事情，我们可以使用一个工具，commitizen 帮助我们编写规范 commit message 的工具。

1.安装Commitizen

npm install commitizen -D

2.安装cz-conventional-changelog，并且初始化cz-conventional-changelog：

npx commitizen init cz-conventional-changelog --save-dev --save-exact

这个命令会帮助我们安装cz-conventional-changelog ，并且在package.json中进行配置：

{
  "config": {
    "commitizen": {
      "path": "./node_modules/cz-conventional-changelog"
    }
  }
}

这个时候我们提交代码需要使用

git cz
image-20230811192649172
  • 第一步是选择type，本次更新的类型
Type作用
feat新增特性 (feature)
fix修复 Bug(bug fix)
docs修改文档 (documentation)
style代码格式修改(white-space, formatting, missing semi colons, etc)
refactor代码重构(refactor)
perf改善性能(A code change that improves performance)
test测试(when adding missing tests)
build变更项目构建或外部依赖（例如 scopes: webpack、gulp、npm 等）
ci更改持续集成软件的配置文件和 package 中的 scripts 命令，例如 scopes: Travis, Circle 等
chore变更构建流程或辅助工具(比如更改测试环境)
revert代码回退

commit提交验证

如果我们按照cz来规范了提交风格，但是依然有同事通过 git commit 按照不规范的格式提交应该怎么办呢？

  • 我们可以通过commitlint来限制提交；

1.安装 @commitlint/config-conventional 和 @commitlint/cli

npm i @commitlint/config-conventional @commitlint/cli -D

2.在根目录创建commitlint.config.js文件，配置commitlint

module.exports = {
  extends: ['@commitlint/config-conventional']
}

3.使用husky生成commit-msg文件，验证提交信息：

npx husky add .husky/commit-msg "npx --no-install commitlint --edit $1"
avatar
文章
阅读
粉丝