IT知识文章:
在过去的很长一段时间中，我们都说CSS是不带有任何逻辑的，意思是在CSS中没有控制流，也没有某种类似于其他编程语言的方式来组织CSS。CSS天生缺乏逻辑性的问题导致了预处理器的出现。然而业界却对CSS预处理器褒贬不一，支持预处理器的人认为这弥补了CSS缺失的特性;而反对预处理器的人则认为CSS的设计初衷就不应该带有逻辑性，他们认为根本不应该引入预处理器这个概念。
ifexists(.btn-text){
#Dothis.
}
每当为选择器添加一层限制，其实我们也就是添加了额外的一个if语句。这会导致圈复杂度问题(CyclomaticComplexity)。
圈复杂度
在软件工程中，圈复杂度是一种程序复杂性的一种度量标准，它一般计算程序中的控制流的数量(如if,else,while等)。程序中存在越多的控制流，则圈复杂度就越高。我们自然想要*圈复杂度能够尽量地低，因为圈复杂度越高：
代码就越难推导
更多潜藏着的、可能会导致失败的问题
代码更难以修改、维护以及复用
你需要考虑更多代码执行的结果与其副作用
编写测试代码的难度也会更高
从圈复杂度的角度来思考CSS的解析过程，我们可以看到浏览器在渲染样式之前需要做许多的决定。我们写的选择器中的if语句越多，这个选择器的圈复杂度就越高，这也意味着我们写的选择器越糟糕，为了使得这一条选择器规则满足，就有需要匹配更多的条件。同时，我们写的选择器也会缺乏清晰度和复用性，因为引入了过多不必要的if语句会导致不准确的匹配(falsepositive)。
圈复杂度对于CSS来说可能是一种比较高阶的原则，但如果我们通过它来考量那些蕴含在我们写的选择器中的逻辑性，那我们也许就能写出更加优秀的代码。
一些易于遵守的小规则，
让你的选择器最简化：每一次你想要为选择器添加规则时，你都在添加额外的if语句。将这些if语句大声地读出来，仔细考虑它们是否有添加的必要。你需要时刻保持你写的选择器足够合理与简洁。
*圈复杂度最小化:使用像Parker这样的工具来测试你写的选择器的圈复杂度(参考文档：IdentifiersPerSelector)
如果你不需要这个检验条件，那就不要把它放进选择器:有时在CSS中使用嵌套结构是有必要的，可在大多数时候并不是，你甚至不能完全相信InceptionRule。
从右边考虑选择器如何编写:从需要匹配的那类元素开始，写尽量少的额外的CSS代码来完成一次正确的匹配。
写选择器时拥有明确的目的性:确保你写的选择器确实是你想要的，而不是那些碰巧能使得页面正常显示的代码。
你的选择器是你的CSS结构最基本的组成部分，一定要确保你写的代码足够合理而简练。
如果你想要学习web前端开发，但对于海文及其web前端开发课程并不是很了解，可以在线咨询客服，
