巧妙的代码

本周，Chris Ferdinandi 审查了一个 巧妙的 JavaScript 代码片段，该片段以新语法特性创造性地编写，但可能可读性和性能较差。 它读起来很快，但他对我们行业对巧妙性的迷恋的提醒值得…… 提醒

……作为行业，我们已经痴迷于简洁和巧妙的代码，这导致代码有时性能较差，并且通常难以阅读和理解。

上个月底，当他写关于 代码可读性 时，他也提出了类似的论点，指出简洁可能看起来很酷，但最终会导致代码库出现各种问题。

通常，Web 开发人员痴迷于简洁。 开发人员会尝试用最少的字符数编写相同的函数。

我个人认为简洁毫无意义。 可读性更为重要。

我完全同意 Chris 的观点，但是，我认为需要做出一个重要的区别，那就是原型代码和生产代码之间的区别。 正如 Jeremy Keith 之前论证的那样

有趣的是，在原型设计方面，我们通常的前端优先级可以并且应该抛到脑后。 现在的优先级是速度。 如果这意味着牺牲语义或性能，那就这样吧。 如果我正在构建原型，并且发现自己想“现在，这个组件的正确类名是什么？”，那么我知道我的思维方式错了。 这个问题对于生产代码来说可能是有效的，但对于原型来说是浪费时间。

我同意 Chris 的观点，即在生产环境中，我们应该编写易于阅读的代码。 我也认为，在原型设计方面，以这种方式试验代码是一件好事。 我们永远不应该回避玩代码和稍微推动一下——只要我们不在一个大型的 Web 应用程序中这样做，并且有一组其他开发人员与我们一起工作。

---

我注意到有些人正在使用 Sass 做出真正巧妙的事情。 我一直坐在那里想，“哇，我以前从未见过这样的东西。” 但是当涉及到必须由数百人同时理解的生产 Web 应用程序时，我不认为当有人查看代码时，这是我们想要的反应。

因此，我一直在尝试编写实际上非常简单的 Sass 代码，几乎看起来很愚蠢。 使代码更简单的一种简单方法是减少嵌套量。

.element {
  .heading { ... }
}

当内部有代码时，这看起来不错——而且很容易理解——但是将复杂的设计混合进来（例如，使用伪元素和媒体查询），您突然面前出现了一组相当复杂的规则。 创造力和巧妙性可能更难以扫描和识别您正在寻找的代码的一小部分。 此外，在本例中，我们不必要地使我们的 .heading 类稍微更具体了一些，这可能会鼓励我们在代码库的其他地方以一种不规范的方式覆盖它们。

我们可以编写如下代码

.element { ... }

.element-heading { ... }

我知道这看起来愚蠢地简单，但是这两个类之间的关系更容易看到，并且将来更容易扩展。 将所有这些代码捆绑到一个嵌套类中可能会很快失控。 即使它碰巧看起来更酷。

（顺便说一句，Andy Bell 关于在 Sass 中使用与号的文章——以及由此产生的评论——是创造力和实用性之间冲突的一个很好的例子。）

无论如何，我在这里要说明的重点是，CSS（以及 JavaScript）是一种奇怪的语言，因为您无法对其制定明确的规则。 这实际上都取决于代码库和项目。 但我认为我们可以肯定地说，当我们的代码转移到生产环境时，我们的代码 应该更加无聊。

继续制作狂野和实验性的或不可能奇怪的原型！ 代码质量无关紧要。