前端代码规范
多人协作开发过程中的代码规范就显得尤为重要，并不是说统一之后规范一定就比规范外的语言规范就要好，目的是多人合作开发中统一了规范，代码风格趋向统一。这样在维护项目代码的时候，与别人交接项目后减少沟通和时间成本。
前言
语言规范除了口头约定，可以借助工具来完成约束。工具可以是编辑器层的也可以是代码层的。下面我的阐述我写的语言规范会在在约定中尽量写到我是怎么遵守这些约定，有没有借助工具来实现。
正文
尽量基于主流的语言规范作为一套统一的语言规范，然后基于上面进行改造，改造的过程中不能破坏语言的稳定性，易读性。下文提到的编辑器工具插件都是基于vsCode来进行阐述。
注释规范
可用工具：JSDOC插件(Document this)和vsCode自带的用户代码片段。
开发者的注释水平的先决条件是代码命名和注释能力，一个好的注释应该让别人一眼就能理解代码的功能作用。jsdoc是前端普遍认可的代码书写规范。使用vscode的朋友可以使用js注释插件Document this来完成注释的模板创建，也可以使用vscode自带的代码片段来完成。也没有什么优劣之分，只是看个人爱好。
- JSDOC
DOcument this
- Vscode 代码片段
Vscode 代码片段
有很多的开发者觉得个人写的代码很清晰很优雅，根本不用写注释。其实我个人观点觉得代码写清晰注释这个是基本要求。代码优雅和使用了过多的语法糖之后相反会使别人难以理解。注释本身就是代码的组成部分。
同时也要避免为了写注释而写注释，一个好的注释不应该是没有用的注释，应该详细描绘其描写的功能函数参数的作用，目的，副作用，缺点，适用范围。
单个文件行数限制
请限制单个文件代码在300行。
- 限制方式：eslint
- 解决方法：模块化、组件化
- 目的：代码易读性优雅型
max-lines: ["error", {"max": 300, "skipBlankLine": false, "skipComments": false}]
接口规范
RestFul Api ---》 使用Post/Get
命名规范
约定
- 默认使用驼峰命名(addProject)
- 组件的命名首字母需要大写
- css的class名同样推荐使用驼峰命名法(由于Cssmodel的影响，不使用中横线，同时也方便鼠标或者键盘取词)
- 常量大写
- 尽量全写(使别人观词得义)
- 文件名都尽量小写，然后使用下划线作为划分词义
可用工具
eslint,编辑器代码风格工具Prettier.
推荐的话还是推荐eslint配合vscode保存修正。可以节省不少工作量，如果使用的Prettier，交接项目的时候，对方的电脑的Prettier使用的可能是自定义规则，出来的代码风格又会出现差异。这个只能约束代码层级的代码风格，不过也够了，eslint的代码风格约束是现在主流的前端代码语法检测工具。
eslint保存约束
Eslint中文网 , 驼峰命名法可以使用eslint规则的camelcase来进行约束。
typescript
前端主流强类型方案。由vscode东家微软开源方案，vscode内置支持，(微软开源还是挺香的)。typescript对于我来说不只是代码类型检查工具，真正吸引我们的应该是其类型提示带来的无数友好代码提示，代码都是有迹可循。2020年了，是时候试用typescript了。
typescript，检查的代码逻辑层的错误，约束的也是代码逻辑层。
套用笔者同事的一句话，typescript，一路提示一路TAB,火车带闪电，代码写好了。约束工具也是生产工具。
小结
以上，皆是笔者对于代码规范进行的一些实践和一些想法。开发前端到现在应该也有三个年头，刚好碰上了前端的繁荣时代，所幸在时代的浪潮下接触了这么多有趣的东西。希望会越来越好。未完
网友评论