前端规范化

TIP

最后更新时间:2019年09月19日

字数:24960

多学习,提高自己的技术,这样才不会被淘汰

都说“没有规矩,不成方圆”,我们程序员在开发产品的过程中也要遵守规矩和规范,这样才能够最大程度上提高开发效率和提升开发质量

学习资源

主要内容

  • 项目规范
    • gitignore
      • git代码管理文件忽略规范
    • package.json
      • 项目各种模块,项目信息配置文件
    • README.md
      • 项目介绍文件
  • 编辑器规范
    • EditorConfig
      • 编辑器配置文件
    • Prettier
      • 代码格式化工具
  • 代码规范
    • html和css规范
      • HTMLHint
        • 用于HTML代码的静态检查
      • CSSLint
        • 用于CSS代码的静态检查
      • stylelint
        • 强大的CSS审查工具(重点)
  • JavaScript规范
    • JSLint
    • JSHint
    • JSCS
    • ESLint
      • 新一代代码规范工具(重点)

gitignore

开发场景

  • 有些时候我们会把一些文件放到Git工作目录中,但又不能提交它们,比如保存了数据库密码的配置文件,日志,临时文件,编译的中间文件等

  • 这些文件我们都是不需要并且有时候不允许提交到Git上面去的,所以我们需要配置响应的规范,来忽略这些文件,让Git提交的时候,不提交这些文件

  • 我们可以在Git工作区的根目录下创建一个特殊的.gitignore文件,然后把要忽略的文件名填进去,Git就会自动忽略这些文件

TIP

注意这个文件是点开头的.gitignore

配置原则

  • 忽略操作系统自动生成的文件,比如缩略图等
  • 忽略编译生成的中间文件、可执行文件等,也就是如果一个文件是通过另一个文件自动生成的,那自动生成的文件就没必要放进版本库,比如Java编译产生的.class文件
  • 忽略你自己的带有敏感信息的配置文件,比如存放口令的配置文件,数据库信息等核心配置文件

TIP

gitignore不用我们自己从头编写,网络上或者github都有现成的配置,找到适合自己的,再添加一些自己的配置即可

GitHub准备的各种gitignore配置文件

使用教程

项目配置和全局配置

  • gitignore可以在项目中配置,当然也是可以指定全局的
  • 这种全局方式在不同的项目开发者之间是不共享的,是属于项目之上Git应用级别的行为
// 全局配置
// 1.创建相应的 .gitignore 文件,可以放在任意位置
// 2. 命令配置Git
git config --global core.excludesfile ~/.gitignore
1
2
3
4

配置文件(项目,非全局)

  • 在工作区新建一个名称为.gitignore的文件
  • 复制各种别人写好的模板,然后自己修改
  • 把要忽略的文件名填进去,Git就会自动忽略这些文件

忽略规则

Git 忽略规则优先级

在 .gitingore 文件中,每一行指定一个忽略规则,Git 检查忽略规则的时候有多个来源,它的优先级如下(由高到低

  • 从命令行中读取可用的忽略规则
  • 当前目录定义的规则
  • 父级目录定义的规则,依次递推
  • $GIT_DIR/info/exclude 文件中定义的规则
  • core.excludesfile中定义的全局规则

Git 忽略规则匹配语法

在 .gitignore 文件中,每一行的忽略规则的语法如下:

  • 空格不匹配任意文件,可作为分隔符,可用反斜杠转义
  • # 开头的文件标识注释,可以使用反斜杠进行转义
  • ! 开头的模式标识否定,该文件将会再次被包含,如果排除了该文件的父级目录,则使用 ! 也不会再次被包含,可以使用反斜杠进行转义
  • / 结束的模式只匹配文件夹以及在该文件夹路径下的内容,但是不匹配该文件
  • / 开始的模式匹配项目跟目录
  • 如果一个模式不包含斜杠,则它匹配相对于当前 .gitignore 文件路径的内容,如果该模式不在 .gitignore 文件中,则相对于项目根目录
  • ** 匹配多级目录,可在开始,中间,结束
  • ? 通用匹配单个字符
  • [] 通用匹配单个字符列表

常用匹配示例

  • bin/: 忽略当前路径下的bin文件夹,该文件夹下的所有内容都会被忽略,不忽略 bin 文件
  • /bin: 忽略根目录下的bin文件
  • /*.c: 忽略 cat.c,不忽略 build/cat.c
  • debug/*.obj: 忽略 debug/io.obj,不忽略 debug/common/io.obj 和 tools/debug/io.obj
  • **/foo: 忽略/foo, a/foo, a/b/foo等
  • a/**/b: 忽略a/b, a/x/b, a/x/y/b等
  • !/bin/run.sh: 不忽略 bin 目录下的 run.sh 文件
  • *.log: 忽略所有 .log 文件
  • config.php: 忽略当前路径的 config.php 文件

删除已经被管理的文件

  • git rm
    • 当我们需要删除暂存区分支上的文件
    • 同时工作区也不需要这个文件了
 git rm file_path
 git commit -m 'delete somefile'
 git push
1
2
3
  • git rm --cached
    • 当我们需要删除暂存区分支上的文件, 但本地又需要使用
    • 只是不希望这个文件被版本控制
git rm --cached file_path
git commit -m 'delete remote somefile'
git push
1
2
3

TIP

推荐大家学习的Git教程:

Git使用教程

package.json

npm

什么是npm

  • npm中文文档

  • npm 是一个Node包管理器,它让 JavaScript 开发者分享、复用代码更方便

  • 它的主要功能就是管理node包,包括:安装、卸载、更新、查看、搜索、发布等

TIP

npm将开发者从繁琐的包管理工作(版本、依赖等)中解放出来,更加专注于功能的开发

npm基本使用

  • npm的安装、卸载、升级、配置
  • npm的使用:package的安装、卸载、升级、查看、搜索、发布
  • npm包的安装模式:本地 vs 全局
  • package.json:包描述信息
  • package版本:常见版本声明形式

TIP

本部分主要讲解package.json教程,npm教程请在本网站别的部分查看 npm教程1 npm教程2

package.json

  • Node管理本地安装 npm 包的最好方式就是创建 package.json 文件

package.json作用

  • 作为一个描述文件,描述了你的项目依赖哪些包
  • 允许我们使用 “语义化版本规则”指明你项目依赖包的版本
  • 让你的构建更好地与其他开发者分享,便于重复使用

TIP

  • package.json文件很重要,如果出错,项目可能就废掉了!
  • package.json文件文件中不允许出现注释!不允许注释!不允许注释!

创建package.json

  • npm init
    • 会问你一系列问题,其实就是package的一些配置(项目的一些配置)
    • 输入内容或者选择默认即可
  • npm init -y (yes也行)
    • 自动创建,问题全都是默认的选项
    • 注意:项目文件目录不允许中文,否则报错

package.json解析

DEFAULT VALUES

  • npm设置了一些默认参数
  • "scripts": {"start": "node server.js"}
    • 如果模块根目录下有一个server.js文件,那么npm start会默认运行这个文件。
  • "scripts":{"preinstall": "node-gyp rebuild"}
    • 如果模块根目录下有binding.gyp, npm将默认用node-gyp来编译preinstall的脚本
  • "contributors": [...]
    • 若模块根目录下有AUTHORS 文件,则npm会按Name (url)格式解析每一行的数据添加到contributors中,可以用#添加行注释

name

  • 项目名称

  • 全部小写

  • 不允许有空格

  • 不能以"."(点)或者"_"(下划线)开头

  • 可以使用下划线或者横线

  • 长度必须小于等于214个字符

  • name最终将被用作URL的一部分、命令行的参数和文件夹名。因此,name不能含有非URL安全的字符

  • 具体name安全规则,大家可以百度一下(记住name不是随便写的哦)

version

  • 项目版本号
  • 版本号必须能被semver解析(也不是随便写的哦)
  • x.x.x 的格式
  • 符合“语义化版本规则”

TIP

  • name和version字段是package.json文件中最重要的字段

  • 都是必须的字段,如果你的npm包没有指定这两个字段,将无法被安装

  • name和version字段被假定组合成一个唯一的标识符

  • 包内容的更改和包版本的更改是同步的

description

  • 包的描述,是一个字符串
  • 它可以帮助人们在使用npm search时找到这个包

keywords

  • npm包的关键字
  • keywords是一个字符串的数组
  • keywords可以帮助人们在使用npm search时找到这个包

homepage

  • 项目主页url

bugs

  • 该项目的issue跟踪页面或这报告issue的email地址,示例如下:
{ 
  "url" : "https://github.com/user/project/issues",
  "email" : "project@hostname.com"
}
1
2
3
4

license

  • 项目许可证,让使用者知道是如何被允许使用此项目
  • 默认是ISC
  • 项目协议可以是基于多个协议,也可以自定义协议,具体请自行百度

author

  • 项目作者
  • 只能是一个人

contributors

  • 包的其他贡献者
  • 必须是一个数组,里面每个元素都是对象(或者字符串,npm会帮我们解析),对象必须有name字段和可选的url和email字段
{
    "name": "xiaofengge",
    "email": "admin@xuefeng666.com",
    "url": "http://www.xuefeng666.com/"
}
1
2
3
4
5

TIP

npm会使用你提供的npm用户信息来设置一个顶级的"maintainers"字段

file

  • files字段是一个被项目包含的文件名数组
  • 如果你在里面放一个文件夹名,那么这个文件夹中的所有文件都会被包含进项目中(除非是那些在其他规则中被忽略的文件)

TIP

file配置挺复杂的,这里就不展开赘述了,具体大家自行百度

main

  • 指定了加载的入口文件
  • require(‘模块名称’) 会加载这个文件
  • 默认值是模块根目录下面的index.js

bin

  • 用来指定各个内部命令对应的可执行文件的位置
  • 很多的包都会有执行文件需要安装到PATH中去
  • 这个字段对应的是一个Map,每个元素对应一个{ 命令名:文件名 }
    • 在安装时,如果是全局安装,npm将会使用符号链接把这些文件链接到prefix/bin,如果是本地安装,会链接到./node_modules/.bin/
// 当你安装myapp,npm会从cli.js文件创建一个到/usr/local/bin/myapp的符号链接(这使你可以直接在命令行执行myapp)
{ "bin" : { "myapp" : "./cli.js" } }
1
2

TIP

  • 如果你只有一个可执行文件,那么它的名字应该和包名相同,此时只需要提供这个文件路径(字符串)
  • "bin": "./path/to/program"等同于"bin": {"my-program": "./path/to/program"}

man

  • 指定一个单一的文件名或一个文件名数组
  • 类似于linux命令中的man 命令,来查看一个命令的用法

directories

  • CommonJs通过directories来制定一些方法来描述模块的结构
  • directories.lib
    • 告诉用户模块中lib目录在哪,这个配置目前没有任何作用,但是对使用模块的人来说是一个很有用的信息。
  • directories.bin
    • 如果你在这里指定了bin目录,这个配置下面的文件会被加入到bin路径下,如果你已经在package.json中配置了bin目录,那么这里的配置将不起任何作用。
  • directories.man
    • 指定一个目录,目录里边都是man文件,这是一种配置man文件的语法糖。
  • directories.doc
    • 在这个目录里边放一些markdown文件,可能最终有一天它们会被友好的展现出来(应该是在npm的网站上)
  • directories.example
    • 放一些示例脚本

repository

  • 指明你的代码被托管在何处,这对那些想要参与到这个项目中的人来说很有帮助。
  • 如果git仓库在github上,用npm docs命令将会找到你
{
    "repository": {
        "type": "git",
        "url": "https://github.com/npm/npm.git"
    }
}
1
2
3
4
5
6

TIP

注意:

  • url应该是公开且可用的(可能是只读的),这个url应该可以被版本控制系统不经修改地处理。
  • 不应该是一个在浏览器中打开的html项目页面,这个url是给计算机使用的。

scripts

  • scripts属性是一个对象
  • 里边指定了项目的生命周期个各个环节需要执行的命令
  • key是生命周期中的事件,value是要执行的命令
// npm自带的
prepublish: 在包发布之前运行,也会在npm install安装到本地时运行
publish,postpublish: 包被发布之后运行
preinstall: 包被安装前运行
install,postinstall: 包被安装后运行
preuninstall,uninstall: 包被卸载前运行
postuninstall: 包被卸载后运行
preversion: bump包版本前运行
postversion: bump包版本后运行
pretest,test,posttest: 通过npm test命令运行
prestop,stop,poststop: 通过npm stop命令运行
prestart,start,poststart: 通过npm start命令运行
prerestart,restart,postrestart: 通过npm restart运行
1
2
3
4
5
6
7
8
9
10
11
12
13
// 自定义的命令
"scripts": {
    "dev": "node build/dev-server.js",
    "build": "node build/build.js",
    "unit": "cross-env BABEL_ENV=test karma start test/unit/karma.conf.js --single-run",
    "test": "npm run unit",
    "lint": "eslint --ext .js,.vue src test/unit/specs"
  },
1
2
3
4
5
6
7
8

config

  • 配置项目中需要的配置参数
  • 用来设置一些项目不怎么变化的项目配置,比如端口号
{ 
	"name" : "foo" , 
	"config" : 
    	{ 
            "port" : "8080" 
        } , 
	"scripts" : 
    	{ 
            "start" : "node server.js" 
        } 
} 
1
2
3
4
5
6
7
8
9
10
11
  • server.js中使用process.env.npm_package_config_port来访问port
  • 用户也可以这样修改:npm config set foo:port 80
  • 参考资料

TIP

  • -S, --save 安装包信息将加入到dependencies(生产阶段的依赖)
  • -D, --save-dev 安装包信息将加入到devDependencies(开发阶段的依赖),所以开发阶段一般使用它
  • -O, --save-optional 安装包信息将加入到optionalDependencies(可选阶段的依赖)
  • -E, --save-exact 精确安装指定模块版本

dependencies(生产)

  • 项目在生产环境中依赖的包
  • 一个对象,该对象的各个成员,分别由模块名(key)和对应的版本要求(value)组成
  • 它指定了依赖的包名和其版本范围的映射
  • 版本范围是个有一个或多个空白分隔描述符的字符串
version 精确匹配版本
>version 必须大于某个版本
>=version 大于等于
<version 小于
<=versionversion 小于
~version "约等于",具体规则详见semver文档
^version "兼容版本"具体规则详见semver文档
1.2.x 仅一点二点几的版本
http://... 见下面url作为denpendencies的说明
任何版本
"" 空字符,和*相同
version1 - version2 相当于 >=version1 <=version2.
range1 || range2 范围1和范围2满足任意一个都行
1
2
3
4
5
6
7
8
9
10
11
12
13
  • URLs as Dependencies
    • 在版本范围的地方可以写一个url指向一个压缩包,模块安装的时候会把这个压缩包下载下来安装到模块本地
  • Git URLs as Dependencies
git://github.com/user/project.git#commit-ish
git+ssh://user@hostname:project.git#commit-ish
git+ssh://user@hostname/project.git#commit-ish
git+http://user@hostname/project/blah.git#commit-ish
git+https://user@hostname/project/blah.git#commit-ish
1
2
3
4
5
  • commit-ish 可以是任意标签,哈希值,或者可以检出的分支,默认是master分支
  • GitHub URLs
    • 支持github的 username/modulename 的写法,#后边可以加后缀写明分支hash或标签:
{
  "name": "foo",
  "version": "0.0.0",
  "dependencies": {
    "express": "visionmedia/express",
    "mocha": "visionmedia/mocha#4727d357ea"
  }
}
1
2
3
4
5
6
7
8
  • Local Paths
    • npm2.0.0版本以上可以提供一个本地路径来安装一个本地的模块,通过npm install xxx --save 来安装,格式如下:
../foo/bar
~/foo/bar
./foo/bar
/foo/bar


package.json 生成的相对路径如下:
{
  "name": "baz",
  "dependencies": {
    "bar": "file:../foo/bar"
  }
}

这种属性在离线开发或者测试需要用npm install的情况,又不想自己搞一个npm server的时候有用,但是发布模块到公共仓库时不应该使用这种属性
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

devDependencies(开发)

  • 是一个对象,配置模块依赖的模块列表,key是模块名称,value是版本范围
  • 该模块中所列举的插件属于开发环境的依赖(比如:测试或者文档框架等
  • 通过你npm install进行依赖安装时加上-save-dev,devDependencies对象中便会增加echarts安装配置

peerDependencies

  • 如果你的包是插件,适合这种方式
  • 在某些情况下,当一个主机无法require依赖包时,你会想要告诉它还有哪些工具或库与这个依赖包兼容。这通常被成为一个插件

bundledDependencies

  • 在发布包时,包名的数组会被打包进去
  • 发布包时同时打包的其他依赖。

optionalDependencies

  • 如果你想在某些依赖即使没有找到,或则安装失败的情况下,npm都继续执行。那么这些依赖适合放在这里。
  • 通过 -o安装

engines

  • 可以指定npm和nodejs版本
  • 如果不指定,就是任意版本
"engines": {
   "node": ">=0.10.3 <10.1",
   "npm": ">= 3.0.0"
 },
1
2
3
4

engineStrict

  • npm 3.0.0 之后被弃用了

OS

  • 可以指定你的模块只能在哪个操作系统上跑
  • 可以设置黑名单和白名单
{
    // 白名单
	"os" : [ "darwin", "linux" ],
	// 黑名单
	"os" : [ "!win32" ]
}
1
2
3
4
5
6

cpu

  • 限制模块只能在某某cpu架构下运行
  • 可以设置黑名单和白名单
{
    // 白名单
    "cpu" : [ "x64", "ia32" ],
    // 黑名单
    "cpu" : [ "!arm", "!mips" ]
}
1
2
3
4
5
6

preferGlobal

  • 可选字段,布尔值。
  • 如果你的包是个命令行应用程序,需要全局安装,就可以设为true。

Private

  • 可选字段,布尔值。
  • 如果private为true,npm会拒绝发布。这可以防止私有repositories不小心被发布出去。
  • 如果你只想让模块被发布到一个特定的npm仓库,如一个内部的仓库,可与在下面的publishConfig中配置仓库参数。

publishConfig

  • 可选字段。发布时使用的配置值放这。

  • 这个配置是会在模块发布时用到的一些值的集合。

  • 如果你不想模块被默认被标记为最新的,或者默认发布到公共仓库,可以在这里配置tag或仓库地址。

README.md

项目开发中项目文档是比不可少的,我们在github上面会看到每个项目都有一个README.md的文件,其实这个就是一个简单的项目介绍文档

README.md文件作用

  • README.md文件是一个项目的入门手册
  • 它里面介绍了整个项目达到什么样子的效果、需要搭建什么样的环境、具备什么样的技能等等。
  • README文件写得好不好,关系到这个项目能不能更容易的被其他人使用。

README.md文件命名规范

推荐参考Github写法使用大写字母,以便于和普通代码文件做区分

README.md 即可

README.md文件内容规范

TIP

开源项目文档和公司内部项目文档是不同的,大家具体情况具体分析

最好包含以下几个部分:

  • 项目背景介绍
  • 项目基本介绍
  • 项目开发环境
  • 项目启动或者使用说明(重要)
  • 项目API参考(重要)
  • 项目功能描述(重要)
  • 项目结构简介(内部项目)
    • 项目一些配置文件说明
    • 项目重要代码文件说明
    • 项目敏感文件说明
  • 测试DEMO
  • 项目测试运行效果
  • 作者列表
  • 更新链接
  • 历史版本
  • 联系方式
  • 开源协议

TIP

上面这些选项只是推荐大家编写,项目文档每个项目都不一样,也没用强制要求规范!

如果是面向全世界的开源项目,应该中英文两份README.md文件

不过有许多中国人开源的项目,却只写一份英文README.md文件,很尴尬!!!

项目背景介绍

  • 简单介绍下项目编写的背景
  • 项目编写的初衷之类的,项目创作的动机之类的(一般都是我们抒发情怀的地方)

项目基本介绍

  • 也可以和项目背景介绍合在一起
  • 解释下项目到底是什么,解决了什么问题
  • 介绍项目为什么编写,解决了什么问题,未来可能会解决什么问题等

TIP

类似网络小说中的开篇,一般都是解释三个问题:

我是谁(小峰哥)?我在哪(地球)?我要干什么(写博客)?

项目开发环境

  • 介绍自己项目是在什么环境下开发的
  • 虽然项目可能是通用环境都可以运行,但是推荐还是写一下
  • 万一有人想要编译重写我们的项目,最起码有个指引不是

项目启动或者使用说明(重点)

  • 我们拿到一个项目,一开始肯定是要知道项目怎么用
  • 所以,我们的项目文档必须有详细的项目启动说明和使用说明
  • 必须让用户可以根据说明,非常简单的使用我们的项目

项目功能描述(重点)

  • 这里是我们的闪光点,展示我们项目的优势和功能,来吸引用户使用我们的项目
  • 项目功能描述要详细,要做好功能分类,有条理的介绍下项目的功能
  • 让用户可以非常简单的了解我们的项目,非常简单的找到他需要的功能,并且使用我们的项目

项目API参考(重点)

  • 根据项目的大小,如果它足够小且足够简单,则可以将参考文档添加到README中。
  • 对于中型到大型项目,至少提供API参考文档所在位置的链接非常重要
  • 要让用户很简单的找到怎么参考API来使用和运行我们的项目

项目结构简介

  • 一般这个是公司内部项目文档需要写的,因为如果新人接手项目,有一份目录介绍文档和一些逻辑和重要代码文档,可以帮助新人很快的熟悉和接手项目
  • 如果项目有一些重要的配置文件(比如,数据库的配置,开发环境和线上环境的配置,一些报错配置,一些协议配置等),那么我们的项目文档肯定要针对这些文件做描述的
  • 如果我们项目有一些重要的逻辑,和一些重要的修改,当开发人员觉得项目中的注释或者版本提交记录不足以描述很清楚的时候,可以在项目中添加这些代码的说明,这也是可以的

项目测试DEMO

  • 一个项目测试Demo是必不可少的
  • 只告诉用户怎么配置,不给用户Demo,万一用户按照我们的指导运行不成功怎么办
  • 程序员喜欢用Demo说话,同时我们的用户也喜欢通过DEMO来了解我们的项目
  • 这就要求我们在项目文档中提供项目demo下载地址或者项目demo的github等

项目测试运行效果

  • 描述并展示如何使用代码示例运行测试
  • 并且提供项目的测试结果

项目作者列表

  • 如果是大型项目,贡献者肯定不止一个人,我们完全有必要或者是必须列举那些为项目做过贡献的人
  • 这不仅仅对他们成绩的肯定,也是对于他们的一种尊重

项目更新链接

  • 项目更新对于开发人员是一件很苦的事情,同事对于我们的用户也是一件痛苦的事情
  • 如果新版本的项目修改了很多,那么我们必须针对每个更新提供有用的信息,供用户参考

项目历史版本

  • 项目历史版本更新情况
  • 项目每个版本的差异等都可以在这里提供链接
  • 一些重要的更新修改,可以在这里重点指出来

项目联系方式

  • 告诉用户项目如果除了Bug或者其他问题,怎么与我们沟通交流

项目开源协议

  • 给出项目的开原协议

TIP

以上是小峰哥关于项目README.md文档编写给出的建议,仅供大家参考!谢谢!

EditorConfig

让使用不同编辑器的开发者在共同开发一个项目时统一地遵循同样的编码规范

开发中的场景

  • 项目开发人员(程序员)硬件配置不同,有人用Windows系统,有人用macOS系统,还有人使用Linux系统
  • 同一个操作系统之间,同一个项目可能会用不同的编辑器或者IDE(集成开发环境),比如有人我们前端开发,有人喜欢用sublime text,有人喜欢用webstorm,有人喜欢用vscode
  • 如果不同的人使用不同的编辑器开发同一个项目,我们怎么做到风格统一呢?
  • 答案:EditorConfig可以帮助我们实现

官网描述

  • EditorConfig帮助开发人员在不同的编辑器和IDE之间定义和维护一致的编码样式。
  • EditorConfig项目由用于定义编码样式的文件格式和一组文本编辑器插件组成,这些插件使编辑器能够读取文件格式并遵循定义的样式。
  • EditorConfig文件易于阅读,并且与版本控制系统配合使用。

使用现状

  • 目前包括Angular js,jQuery,Babel,bootstrap, Django,jade, Node.js, Ionic等许大型知名项目都在使用EditorConfig

使用步骤

  • 第一步:创建一个EditorConfig配置文件.editorconfig在项目根目录
  • 第二部:安装与编辑器对应的 EditorConfig 插件

优先级

EditorConfig配置文件的配置,优先级高于编辑器自身的设置

安装插件说明

  • 不需要安装插件的编辑器(编辑器捆绑了对EditorConfig的原生支持)
  • 需要安装一个插件的编辑器

TIP

实现原理

  • 打开项目时,EditorConfig插件会查找.editorconfig在打开的文件的目录中以及每个父目录中命名的文件
  • .editorconfig如果到达根文件路径或root=true找到了EditorConfig文件,则将停止搜索文件。
  • EditorConfig文件从上到下读取,找到的最新规则优先。
  • 匹配的EditorConfig部分中的属性按其读取顺序应用,因此较近文件中的属性优先。

TIP

推荐项目根目录添加一个EditorConfig配置文件即可,方便统一

编码规范

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

# 找到当前文件,不在向上查询配置文件,以当前配置文件为准
root = true

# Unix-style newlines with a newline ending every file
# UNIX样式的换行符,每个文件都有换行符
[*]
#  换行符格式
end_of_line = lf  
# 是否在文件的最后插入一个空行
insert_final_newline = true

# Matches multiple files with brace expansion notation
# Set default charset
# 所有js或者py结尾的文件 统一文件编码
[*.{js,py}]
charset = utf-8

# 4 space indentation
[*.py]
# 缩进类型 space
indent_style = space
# 缩进数量 整数  一般是2和4
indent_size = 4

# Tab indentation (no size specified)
# 匹配Makefile文件
[Makefile]
indent_style = tab

# Indentation override for all JS under lib directory
# 匹配lib目录下面所有的js文件
[lib/**.js]
indent_style = space
indent_size = 2

# Matches the exact files either package.json or .travis.yml
# 匹配 package.json,.travis.yml 文件
[{package.json,.travis.yml}]
indent_style = space
indent_size = 2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

编码规范示例

符号 说明
* 匹配除路径分隔符(/)之外的任何字符串
** 匹配任何字符串
? 匹配任何单个字符
[name] 匹配名称中的任何单个字符
[!name] 匹配任何不在名称中的单个字符
{s1,s2,s3} 匹配给定的任何字符串(以逗号分隔)
{num1..num2} 匹配num1和num2之间的任何整数,其中num1和num2可以是正数或负数
  • 可以使用反斜杠转义特殊字符,这样它们就不会被解释为通配符模式。
  • charset:文件编码(可选值)
    • latin1
    • utf-8 :一般用这个
    • utf-16be
    • utf-16le
  • indent_style: 缩进类型(可选值)
    • space
    • tab
  • indent_size: 缩进数量(可选值)
    • 整数:一般设置 2 或 4
    • tab
  • insert_final_newline:是否在文件的最后插入一个空行(可选值)
    • true
    • false
  • end_of_line:换行符格式(换行 可选值)
    • lf:一般都用这个
    • crlf
    • cr
  • trim_trailing_whitespace:是否删除行尾的空格(可选值 )
    • true
    • false

我的EditorConfig配置

# indicate this is the root of the project
root = true

# 所有文件配置
[*]
indent_style = space //缩进类型为space
end_of_line = lf // 换行类型lf
charset = utf-8 // 编码统一utf-8
trim_trailing_whitespace = true // 删除行尾的空格
indent_size = 2 // 缩进数量为2

# html文件配置
[*.html]
indent_size = 4 // 缩进为4
max_line_length = 88 // 指定的字符80个后强制强行换行(88数字很吉利)

# 一般下面README.md文件配置
[*.md]
trim_trailing_whitespace = false // 不删除行尾的空格

# package.json文件配置
[package.json]
indent_style = space
indent_size = 4
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

配置文件说明

  • 所有属性和值都不区分大小写
  • 如果未指定属性,则将使用编辑器设置,即EditorConfig对该部分不起作用
  • 对于任何属性,unset的值是删除该属性的效果,即使它之前已设置过。

TIP

推荐大家项目都配置一下EditorConfig,非常好用,并且可以添加到git代码管理,这样团队所有人都可以使用一套配置规范

Prettier

HTMLHint

CSSLint

stylelint

JSLint

JSHint

JSCS

ESLint