配好6个前端规范，CV效率翻倍
作者：陈佬昔的编程人生
虽然大家都知道代码规范很重要，但是真的要落地执行的时候，不少团队没有仔细调查实践，只是简单配置，甚至复制其他公司的规范不加修改就上路了。最后很可能因为某些配置不好用，导致大家的开（C）发（V）效率下降。
而这种配置是伴随整个项目生命周期的，像这样配置错了，后期再来修改，就会十分痛苦。
这里列出几条会影响大家效率的代码规范，它们的正确配置。希望能帮助大家在项目早期设计好前端规范。
顺便吆喝一声机会，技术大厂，前后端捞人
1. 行末必须使用分号
eslint 规则： "semi": ["error", "always"]
80% 的老前端估计都是有写分号习惯的。然而在前端规范发展早期，可能受到python语言影响的，突然出现一派不写分号的规范配置。
行末不带分号，这样写有什么弊端呢？
在我们复制粘贴代码的时候，更多时候使用的是键鼠组合。ctrl + c 复制之后，移动鼠标到某一行，点击将光标置于行末，ctrl + v 粘贴。
然而如果行末不写分号，直接粘贴就报错了。而代码一报错，自动格式化就无效了，这是需要我们手动处理了。或者，在复制完代码后再回来添加换行；亦或者，在开始粘贴前先手动敲一下回车，如果粘贴后发现多了一空行，再删除空行。
整个过程显然比行末带分号的代码要耗时更多。
// 错误代码，复制代码后，引起报错，无法使用自动格式化
import componentA from ''import componentB from ''
另外，在这个规则下，复制代码到 return 后，如果多了换行符，自动格式化时，return 后的代码不会合并到 return 这一行。最后 return 会返回一个空对象，导致整个程序都出 bug。
// 复制内容到 return 后无法自动合并成一行，可能会引起程序 bug。
function doSomething() {
return
somthing
}
2. 对象，数组行末允许逗号
eslint 规则： "comma-dangle": ["error", "always-multiline"]
同上，如果不这么做的话，每次复制过来，都会因为报错导致自动格式化失效，需要自行修改添加逗号。
还有用快捷键 Alt + ⬆️/⬇️ 移动代码块的时候也需要做额外的处理。
// 正确示范
export default {
components: ｛
// 可以轻松的将 commonComponentC 复制到任何一行
commonComponentA,
thisPageComponentA,
thisPageComponentB,
commonComponentB, // 可以轻松地将 commonComponentB 上移，归类
}
}
3. if else 必须带上花括号
eslint 规则："brace-style": ["error", "1tbs", { "allowSingleLine": false }]
同上，如果不这么做的话，复制的时候，还需要阅读前后代码，才能避免不出错。而这种出错甚至是致命性的bug，有可能整个业务逻辑都受影响。
// 错误例子，不添加花括号，容易引起误解
if (condition) return
if (condition2) return array2
// 解读1
if (condition) { return null }
if (condition2) { return array2 }
// 解读2
if (condition) {
return {
if (condition2) { return array2 }
}
}
为了快速地复制移动代码，还是建议代码规范中加上此规则吧。
4. 参数必须带括号，即使只有一个
eslint 规则："arrow-parens": ["error", "always"]
prettier 配置项： --arrow-parens=always
我们都知道，参数越少越好。然而谁也无法料想到，后续需求的发展。
常有的情况是，为了不影响原有的程序运行，需要在这个对象外新增加一个参数。如果你配置了 as-needed， 仅有一个参数时就会省略括号，问题就出现了。
// 报错
const getList = params => {
const res = await axios.get('...', params);
}
// 新增参数报错，自动格式化失效
const getList = params，total => {
const res = axios.get('...', params)
total = res.data.total
}
而且这样配置，没有参数的时候，这个括号也是不省略的，就会给人很奇怪的感觉。
// 没有参数，括号不能省略
const getList = () => axios.get('...')
所以，还是把不省略括号给配置上吧。
5. html 对空格不敏感
prettier 配置项：--html-whitespace-sensitivity = ignore
前端代码在打包的时候会经过压缩的过程。这是一段普通的html代码：
<html>
<body>
<button>按钮1</button>
<button>按 钮 2</button>
</body>
</html>
压缩后的代码如下：
<!-- 这是敏感的 -->
<html><body> <button>按钮1</button> <button>按 钮 2</button> </body></html>
<!-- 这是不敏感的 -->
<html><body><button>按钮1</button><button>按 钮 2</button></body></html>
可以看到。如果设置了html 对空格不敏感，html之间的空格就会被删除，那样我们就可以放心大胆地复制 html 代码了。
然而，不少人会说，这样设置影响到了行内元素之间的间距，应该怎么处理呢？
当然是用 css 完完全全去控制样式。把样式完全交给 css 处理， 这样可以得到更精确的距离。内边距用padding，外边距用 margin，字之间的间隙用 letter spacing。
这样是不是效率更慢了？
并没有，通常来说，这种样式写一个公共样式就够了。如，每个按钮之间需要空隙，可以用相邻节点选择器来解决。
button + button ｛
margin-left: 10px
}
总之，办法总比问题多，而且都是少量的处理。
另外，如果设置了html 对空格敏感，还会出现莫名其妙的十分丑陋的 html 排版，让人抓狂。
<html>
<body>
<button
onClick=“window.open('...')”
>按钮1属性太长需要换行</button>
<button
>按钮2因自身太长自身太长自身太长自身太长需要换行</button>
</body>
</html>
鉴于此，html 对空格不敏感，是最好的选择
6. CSS 中禁用 !important
Stylelint 规则：keyframe-declaration-no-important
我们都知道，CSS 是通过选择器的优先级来决定最终显示的样式的，然而使用 !important 后，浏览器会忽略通常应用于该样式的任何继承或嵌套规则。
如果贪一时方便，使用了!important，就会给我们带来不必要的麻烦。
.button1 {
color: blue !important;
}
.componentA .button1 {
color: red; /*按钮样式再也不生效了*/
}
因为 !important 打破了原有的优先级，导致从其他地方复制过来的 css，就需要做调整。
所以我们应该优先考虑更优雅、层次化的结构和适当的类选择来避免冲突，以确保代码的可读性和长期可维护性。而不是使用 !important。
总结
- 前端 javascript 的虽然允许不写很多符号，但是把符号写完整，能大量提高我们的 CV 效率。
- 而对 html 空格不敏感，除了切实地让样式与结构分离，也能提高我们 CV 效率。
- 对 CSS 禁用 !important，除了能有更好维护的代码，也能让我们更好地跨页面 CV 样式。
总之，代码规范配置会影响整个项目周期，我们在制定规范的时候，应该多尝试对比后，再将其落地。代码可读性增强和效率提高不应该是一个矛盾体，两者中可以取得很好的平衡。
以上就是我总结的几条影响大家cv效率的代码规范。
- 点赞
- 收藏
- 关注作者
评论（0）