一个简单的距离判断，被写成了一段让人反复确认的代码。Fritz的团队需要判断一个点是否在中心点的某个距离范围内，结果有人交出了这样一份"解法"。

问题本身并不复杂

需求很直白：给定一个中心点，判断另一个点是否落在指定半径之内。正常思路是算一下两点之间的距离，再和半径比较，这是最直接也最符合直觉的做法。但写这段代码的人显然没有从这个角度想问题。

代码的逻辑是：以目标点为基准，从 -radius 到 radius 逐一遍历 x 坐标，再对每个 x 遍历同样范围的 y 坐标，然后判断遍历到的每一个坐标是否恰好等于中心点。只要有一个命中，就返回 true，全部走完没有命中，就返回 false。

它检查的不是圆，是方框

这段实现有个关键细节：它遍历的范围是 (x-radius, y-radius) 到 (x+radius, y+radius)，也就是一个正方形区域。这意味着它判断的并不是传统意义上的半径，而是一个方框，或者说用的是曼哈顿距离的度量方式。

问题在于，如果目标本来就是判断一个方框范围，那还有比距离公式更简单的办法——直接用边界比较就够了，根本不需要双重循环。换句话说，这段代码既没有用对方法，也没有选对更省事的替代方案。

暴力枚举代替数学计算

另一个限制是，这种做法只能处理整数坐标点。这一点本身倒不算大问题，但结合整体思路来看，它暴露的是一种完全不同的解题习惯：不去理解问题背后的数学含义，而是用穷举的方式把可能性一个个试过去。

写这段代码的人，似乎从未考虑过"距离"这个概念本身意味着什么。既然不知道两点之间的距离该怎么算，那就干脆把所有可能的坐标都列出来，看看有没有一个能对上。这种思路在逻辑上确实能跑通，但代价是把一个常数时间的计算变成了随半径平方增长的循环。

连吐槽都显得很有创意

Fritz的同事看到这段代码后，表达震惊的方式也让人印象深刻。按照原文的说法，这种"WTF"的反应方式，是作者自己都没想到过的。

而写下这段代码的人，或许只是换了一种完全不同的角度去理解"在范围内"这件事。只是这个角度，离正确答案确实有点远。