北京
一个简单的距离判断，被写成了一段让人反复确认的代码。Fritz的团队需要判断一个点是否在中心点的某个距离范围内，结果有人交出了这样一份"解法"。
问题本身并不复杂
需求很直白：给定一个中心点，判断另一个点是否落在指定半径之内。正常思路是算一下两点之间的距离，再和半径比较，这是最直接也最符合直觉的做法。但写这段代码的人显然没有从这个角度想问题。
代码的逻辑是：以目标点为基准，从 -radius 到 radius 逐一遍历 x 坐标，再对每个 x 遍历同样范围的 y 坐标，然后判断遍历到的每一个坐标是否恰好等于中心点。只要有一个命中，就返回 true，全部走完没有命中，就返回 false。
它检查的不是圆，是方框
这段实现有个关键细节：它遍历的范围是 (x-radius, y-radius) 到 (x+radius, y+radius)，也就是一个正方形区域。这意味着它判断的并不是传统意义上的半径，而是一个方框，或者说用的是曼哈顿距离的度量方式。
问题在于，如果目标本来就是判断一个方框范围，那还有比距离公式更简单的办法——直接用边界比较就够了，根本不需要双重循环。换句话说，这段代码既没有用对方法，也没有选对更省事的替代方案。
暴力枚举代替数学计算
另一个限制是，这种做法只能处理整数坐标点。这一点本身倒不算大问题，但结合整体思路来看，它暴露的是一种完全不同的解题习惯：不去理解问题背后的数学含义，而是用穷举的方式把可能性一个个试过去。
写这段代码的人，似乎从未考虑过"距离"这个概念本身意味着什么。既然不知道两点之间的距离该怎么算，那就干脆把所有可能的坐标都列出来，看看有没有一个能对上。这种思路在逻辑上确实能跑通，但代价是把一个常数时间的计算变成了随半径平方增长的循环。
连吐槽都显得很有创意
Fritz的同事看到这段代码后，表达震惊的方式也让人印象深刻。按照原文的说法，这种"WTF"的反应方式，是作者自己都没想到过的。
而写下这段代码的人，或许只是换了一种完全不同的角度去理解"在范围内"这件事。只是这个角度，离正确答案确实有点远。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
