虽然大家都知道代码规范很重要，但是真的要落地执行的时候，不少团队没有仔细调查实践，只是简单配置，甚至复制其他公司的规范不加修改就上路了。最后很可能因为某些配置不好用，导致大家的开（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 对空格不敏感，html之间的空格就会被删除，那样我们就可以放心大胆地复制 html 代码了。然而，不少人会说，这样设置影响到了行内元素之间的间距，应该怎么处理呢？当然是用 css 完完全全去控制样式。把样式完全交给 css 处理，这样可以得到更精确的距离。内边距用padding，外边距用 margin，字之间的间隙用 letter spacing。这样是不是效率更慢了？并没有，通常来说，这种样式写一个公共样式就够了。如，每个按钮之间需要空隙，可以用相邻节点选择器来解决。 ``` button + button ｛ margin-left: 10px } ``` 总之，办法总比问题多，而且都是少量的处理。另外，如果设置了html 对空格敏感，还会出现莫名其妙的十分丑陋的 html 排版，让人抓狂。 ``` ``` 鉴于此，html 对空格不敏感，是最好的选择 ## 6. CSS 中禁用 !important > Stylelint 规则：keyframe-declaration-no-important 我们都知道，CSS 是通过选择器的优先级来决定最终显示的样式的，然而使用 !important 后，浏览器会忽略通常应用于该样式的任何继承或嵌套规则。如果贪一时方便，使用了!important，就会给我们带来不必要的麻烦。 ``` .button1 { color: blue !important; } .componentA .button1 { color: red; /*按钮样式再也不生效了*/ } ``` 因为 !important 打破了原有的优先级，导致从其他地方复制过来的 css，就需要做调整。所以我们应该优先考虑更优雅、层次化的结构和适当的类选择来避免冲突，以确保代码的可读性和长期可维护性。而不是使用 !important。 ## 总结 1. 前端 javascript 的虽然允许不写很多符号，但是把符号写完整，能大量提高我们的 CV 效率。 1. 而对 html 空格不敏感，除了切实地让样式与结构分离，也能提高我们 CV 效率。 1. 对 CSS 禁用 !important，除了能有更好维护的代码，也能让我们更好地跨页面 CV 样式。总之，代码规范配置会影响整个项目周期，我们在制定规范的时候，应该多尝试对比后，再将其落地。代码可读性增强和效率提高不应该是一个矛盾体，两者中可以取得很好的平衡。以上就是我总结的几条影响大家cv效率的代码规范。大家在日常工作中还碰到哪些？欢迎在评论区留言，我们一起聊聊。