评论

代码规范

组建前端团队时,这是重要却容易忽略的事

组建团队最容易被忽略,又挺重要的事情,就是确定代码规范。

代码规范不是编写有效的代码硬性规定,而是统一代码风格、避免出错的最佳实践。

每个人都有自己的编码风格,并且JavaScript语言极度灵活,约束较少,而且是弱类型语言。如果不对编码的风格做一定的约束,必然出现千差万别的风格,虽然都是正确可执行的代码,但这会让代码的可阅读性非常差。

最好的结果就是每个人写得代码都是一样的。

前端的特殊性

若是后端或者其他岗位,可能就涉及一种编程语言,也就确定一种代码规范即可。

但是前端,涉及到编程语言相对较多,并且不同框架或者runtime也可能导致不同的语法风格,因此需要覆盖的规范也比较多:

  • 编程语言:JavaScript、CSS、HTML
  • 框架:Vue、React
  • runtime:Node.js、小程序、浏览器

笔者认为,最基本的编程语言的代码规范是必须要有的,其他可以陆续完善

实施方案

如果只是制定的代码规范文档,但是没有可实施方案,依靠人为的自觉,必然出现不遵守规则的漏网之鱼。因此,必须落地实施方案,拒绝不符合规范的代码合入代码仓库。

比较常见的方案为Git + GitLab(GitHub) + ESLint。

Git是常用的分布式版本控制系统,GitLab则是开源的仓库管理工具。而ESLint则为主流的JavaScript代码检测工具

每个仓库均可设置多个分支,在GitLab上对关键分支(比如master)的权限做严格把控,比如:

  • 不允许任何人直接push到关键分支(Allowed to push: No one)

  • 仅允许通过pipeline的 合并请求(merge requests) 进行合并

最后在pipeline中添加一个Job,使用ESLint检测当前的代码即可。

快速开始

实施方案确定了,下一步即是制定详细的代码规范。如果重头开始梳理规范,将是极为庞大的工作。

ESLint

好在ESLint提供了推荐方案,在配置文件.eslintrc这样写即可:

{
    "extends": "eslint:recommended"
}

或者采用业界比较出名的公司规范也可以,比如:Google、Airbnb。

使用ESlint --init即可开启交互式初始化ESLint配置。

对于不同的runtime,都是使用ESLint作为检测工具,只不过需要下载第三方插件来扩展检测能力

HTMLHint

因为HTML不算真正的编程语言,而是标记语言,因此可以检测的规范不会太多,因此可以手动梳理一便,同时也支持自定义规则。全部的规则:HTMLHint Rules

通过配置文件.htmlhintrc配置,默认配置如下:

{
   "tagname-lowercase": true,
    "attr-lowercase": true,
    "attr-value-double-quotes": true,
    "doctype-first": true,
    "tag-pair": true,
    "spec-char-escape": true,
    "id-unique": true,
    "src-not-empty": true,
    "attr-no-duplication": true,
    "title-require": true
}

stylelint

类似于ESLint,stylelint也提供了 标准配置(standard configuration),安装方式:

npm install --save-dev stylelint stylelint-config-standard

在项目根目录创建配置文件.stylelintrc.json

{
  "extends": "stylelint-config-standard"
}

执行检测:

npx stylelint "**/*.css"
最后一次编辑于  04-12  
点赞 0
收藏
评论

1 个评论

登录 后发表内容