摘要：天生缺乏逻辑性的问题导致了预处理器的出现。这会导致圈复杂度问题。圈复杂度对于来说可能是一种比较高阶的原则，但如果我们通过它来考量那些蕴含在我们写的选择器中的逻辑性，那我们也许就能写出更加优秀的代码。
本文在征得原作者 @csswizardry 同意的情况下，翻译自他博客中的文章：Cyclomatic Complexity: Logic in CSS。最初发布于我的个人博客：咀嚼之味
另外呢，@hax前辈对本文的原作者的理论嗤之以鼻。所以加一句：尽信书，则不如无书。各位看官自己掂量着吧~
在过去的很长一段时间中，我们都说 CSS 是不带有任何逻辑的，意思是在 CSS 中没有控制流，也没有某种类似于其他编程语言的方式来组织 CSS。CSS 天生缺乏逻辑性的问题导致了预处理器的出现。然而业界却对 CSS 预处理器褒贬不一，支持预处理器的人认为这弥补了 CSS 缺失的特性；而反对预处理器的人则认为 CSS 的设计初衷就不应该带有逻辑性，他们认为根本不应该引入预处理器这个概念。
然而，一种独特的思考方法最近突然蹦入了我的脑袋。它让我感到 CSS 确实拥有逻辑性！很少有人真正那么想过，这大概也是我们一直认为 CSS 的逻辑性匮乏的最大原因吧。
我发现我们可以将复合选择器理解为：主体部分 + 条件部分。首先来看一个例子：
div.sidebar .login-box a.btn span {
/*...*/
}
在这个复合选择器由主体部分是 span，而条件部分是 IF (inside .btn) AND IF (on a) AND IF (inside .login-box) AND IF (inside .sidebar) AND IF (on div)。
也就是说，一个选择器的每一部分都是一个 if 语句，需要在解析选择器时被满足（或者不满足）。有了这种微妙的而又全新的认识，如今我们回头再看看自己曾经写出的 CSS 代码，我们将会意识到选择器写的好或者坏，会对效率产生直接的影响。我们真的会写出下面这段逻辑吗？（伪代码）：
@if exists(span) {
@if is-inside(.btn) {
@if is-on(a) {
@if is-inside(.login-box) {
@if is-inside(.sidebar) {
@if is-on(div) {
# Do this.
}
}
}
}
}
}
也许不会。这看上去太不直接，也太啰嗦了。我们也许只需要这么写：
@if exists(.btn-text) {
# Do this.
}
每当为选择器添加一层限制，其实我们也就是添加了额外的一个 if 语句。这会导致圈复杂度问题（Cyclomatic Complexity)。
圈复杂度在软件工程中，圈复杂度是一种程序复杂性的一种度量标准，它一般计算程序中的控制流的数量（如 if, else, while 等）。程序中存在越多的控制流，则圈复杂度就越高。我们自然想要保证圈复杂度能够尽量地低，因为圈复杂度越高：
代码就越难推导
更多潜藏着的、可能会导致失败的问题
代码更难以修改、维护以及复用
你需要考虑更多代码执行的结果与其副作用
编写测试代码的难度也会更高
从圈复杂度的角度来思考 CSS 的解析过程，我们可以看到浏览器在渲染样式之前需要做许多的决定。我们写的选择器中的 if 语句越多，这个选择器的圈复杂度就越高，这也意味着我们写的选择器越糟糕，为了使得这一条选择器规则满足，就有需要匹配更多的条件。同时，我们写的选择器也会缺乏清晰度和复用性，因为引入了过多不必要的 if 语句会导致不准确的匹配(false positive)。
相比于将 span 嵌套于 .btn 内部并写一大堆限制条件，更好地做法应该是创建一个新的类 .btn-text 来描述这个 span。这样做更加直截了当，同时也更为简洁和健壮（越多的 @if 语句导致选择器规则越不容易被满足）。
值得注意的是浏览器解析你写的选择器的方式：从右向左。如果你在写你的选择器时，第一个想到的问题是：“这是一个 span 元素吗？” 那你通常就会把选择器写的过于冗繁。你应该从另一个角度思考，写出清晰准确的选择器规则，彻底摒弃那些冗余的条件语句。
请不要写过于宽泛的规则，导致你写的选择器在匹配开始时就选中大量的 DOM 元素——然后不得不逐步通过更多的条件语句来删减匹配的对象。从选择器的规则解析的一开始就匹配尽量少的元素才是一种更棒的方法。
圈复杂度对于 CSS 来说可能是一种比较高阶的原则，但如果我们通过它来考量那些蕴含在我们写的选择器中的逻辑性，那我们也许就能写出更加优秀的代码。
一些易于遵守的小规则，
让你的选择器最简化：每一次你想要为选择器添加规则时，你都在添加额外的 if 语句。将这些 if 语句大声地读出来，仔细考虑它们是否有添加的必要。你需要时刻保持你写的选择器足够合理与简洁。
保证圈复杂度最小化: 使用像 Parker 这样的工具来测试你写的选择器的圈复杂度（参考文档：Identifiers Per Selector）
如果你不需要这个检验条件，那就不要把它放进选择器: 有时在 CSS 中使用嵌套结构是有必要的，可在大多数时候并不是，你甚至不能完全相信Inception Rule。
从右边考虑选择器如何编写: 从需要匹配的那类元素开始，写尽量少的额外的 CSS 代码来完成一次正确的匹配。
写选择器时拥有明确的目的性: 确保你写的选择器确实是你想要的，而不是那些碰巧能使得页面正常显示的代码。
你的选择器是你的 CSS 结构最基本的组成部分，一定要确保你写的代码足够合理而简练。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/111074.html
摘要：前端性能优化的涉及点从服务器到协议再到宿主环境本身都要有比较深刻的认识，业界目前主要还是以雅虎总结出来条前端性能优化的黄金军规为参考。 欢迎大家前往腾讯云技术社区，获取更多腾讯海量技术实践干货哦~ 导语 : 从事前端有6年+的时间了，从最开始的美工到重构再到偏向js逻辑开发的前端开发，一直在前端这个行业里面摸索和学习，我现在将自己这些年的一个心得体会来个系统性的梳理写成一篇关于性能优化...
摘要：而且我们不需要了解的特别深，函数式编程很多概念是从范畴论映射过来的。了解范畴论相关概念有助于我们理解函数式编程。函子函子是用来将两个范畴关联起来的。 在前面几篇介绍了函数式比较重要的一些概念和如何用函数组合去解决相对复杂的逻辑。是时候开始介绍如何控制副作用了。 数据类型 我们来看看上一篇最后例子： const split = curry((tag, xs) => xs.split(ta...
摘要：回到纯静态页面开发阶段，让页面不需要后端渲染也能跑起来。改造开始本文着重介绍如何将静态页面改造成后端渲染需要的模板。总结在后端渲染的项目里使用多页应用架构是绝对可行的，可不要给老顽固们吓唬得又回到传统前端架构了。 本文首发于Array_Huang的技术博客——实用至上，非经作者同意，请勿转载。原文地址：https://segmentfault.com/a/119000000820338...
摘要：回到纯静态页面开发阶段，让页面不需要后端渲染也能跑起来。改造开始本文着重介绍如何将静态页面改造成后端渲染需要的模板。总结在后端渲染的项目里使用多页应用架构是绝对可行的，可不要给老顽固们吓唬得又回到传统前端架构了。 本文首发于Array_Huang的技术博客——实用至上，非经作者同意，请勿转载。原文地址：https://segmentfault.com/a/119000000820338...
阅读 3153·2021-11-22 14:45
阅读 3299·2019-08-29 13:11
阅读 2304·2019-08-29 12:31
阅读 920·2019-08-29 11:21
阅读 2989·2019-08-29 11:09
阅读 3614·2019-08-28 18:11
阅读 1417·2019-08-26 13:58
阅读 1270·2019-08-26 13:27
