如果您使用 CSS 有一段时间，那么您就会知道继承、特异性和命名是一些最难处理的事情。由于所有 CSS 都是全局的，随着代码库的增长，防止样式相互冲突并导致意外副作用变得越来越困难!

本文首发于我的个人网站：http://cherryblog.site/ （背景更换了不知道大家有没有发现呢，嘻嘻） 一个好的程序员肯定是要能书写可维护的代码，而不是一次性的代码，怎么能让团队当中其他人甚至一段时间时候你再看你某个时候写的代码也能看懂呢，这就需要规范你的代码了。 …

前言 你是不是有这样的困惑？ 每当接手一个新项目（如果项目中没有配置 eslint husky commit）等这些规范的话，就需要自己手动配置一遍，配置多了就只能来句窝草！😬 公司的项目有的是 vu

不以规矩，不能成方圆。 由于某些原因，笔者有幸经历了团队从缺乏标准到逐渐规范的一个过程，在此当做记录供大家参考。 本文从为什么需要规范以及建立规范的重要性出发，逐步引申出如何去建立适合自身团队的

随着团队人数的增加，每个人的代码编写喜好不同，代码风格也迥然不同。如果有一个大家的统一的愿意遵守的代码规范，肯定事半功倍，提高效率，避免代码Review和重构。 其中一部分规则参考了 腾讯alloyteam团队的代码规范，如有错误，请指出，将会非常感谢。 坚持好的代码风格规范，…

高质量代码编写原则 增加代码可读性，注释清晰、命名语义化；提高代码重用性，公共组件和私有组件的维护，设计公用组件时需要考虑让接口保持弹性，并且高度模块化，多处重复使用不允许轻易被修改，有专人维护

公司一个老项目，没有做代码提交前的校验，我拿到后，想着老项目嘛也没时间帮它弄这些，反正就是改一点点小东西；尽量跟着它的代码风格写，写完提交就行； 直到某一天，又有一个人加入了进来。好家伙，直接干出事

前面我们学习了 eslint 和 stylelint 的规则的写法，当大家实际去写的时候，一定会遇到很多细节的问题，比如解析的代码是有错误的，或者是属性值不足以分析出问题来之类的。我们还需要更多的工具

本篇文章讲怎么在前端团队快速制定并落地代码规范!!!\ 干货，拿走这个[仓库](https://github.com/jd-antelope/s-lint)