技术文章

作为我们内部错误报告基础设施的一部分，我们有一段代码来绘制条形图，其本质上是

DrawRect(x, x+nBarSize*n/nMax, yMin, yMax);

n绘制相对于某个最大值的值的条形图nMax。我省略了一些与本文无关的参数。我们还有一种用于传递矩形的数据类型，而不是一一传递坐标，但这不是今天的主题。

该代码大部分时间都有效，但有时nMax为 0，并且我们遇到了被零除的异常。

第一个修复是这样的：

DrawRect(x, x+nBarSize*n/std::max(1,nMax), yMin, yMax);

在评论中，我们讨论了如何写得最好。如果nMax是 0，我们不想绘制任何条形，所以我们最好根本不调用DrawRect：

if (0<nMax) {
    DrawRect(x, x+nBarSize*n/nMax, yMin, yMax);}

但nMax实际上总是大于或等于n，如果n为 0，我们也不会绘制任何东西。所以我们也可以写

if(0<n) {
    DrawRect(x, x+nBarSize*n/nMax, yMin, yMax);}

我们应该选择哪个？就性能而言，它们是没有区别的，因为n0 的情况非常罕见，并且绘制一个空矩形并不是一个很大的损失。就代码复杂度而言，它们也具有可比性。最后两个都需要比原始代码多一个分支。第一个需要 a std::max，它是一个分支，在本例中是一个常量，但它是 0，所以同样，没有太大区别。

我仍然认为，在给定的代码库中，就选择哪些代码达成一致仍然是一个好主意。在 think-cell，我们将此称为规范解决方案。如果你们没有达成一致，并且每个人都按照自己的意愿行事，那么代码的读者（我们都知道我们主要为人类读者编写代码，其次是为编译器编写代码）可能会问自己是否有更深层次的原因为什么第一个变体被选中而不是第二个，反之亦然：

• 第一个变体允许n大于nMax。是否曾经如此，这就是为什么它不写成0<n？

• 第二种变体不会为 negative 绘制任何内容n。这是否意味着消极的情况n发生了？

我在这里的观点是，不同的变体可能会提出不同的问题，并且只有通过一些商定的规则找到一个规范的变体，读者才会更倾向于认为这些复杂性都没有在这里发挥作用：总是积极的n并且nMax是大于或等于n，顾名思义。

在 think-cell，如果没有其他因素，我们更喜欢更简单的代码而不是更复杂的代码，这可能是我们都同意的一点。但在这个给定的例子中，三个变体的复杂性非常相似，特别是最后两个。所以我们需要另一个决胜局。在 think-cell，我们选择“完成更少的工作”，这有利于最后一个变体。我们这样做并不是为了让我们的程序更快。只有分析才能判断是否确实如此。我们这样做只是为了有一个明智的平局打破者，让我们就规范的内容达成一致。