在检查了该行的历史之后，我的主要结论是工作中存在一些不称职的编程。

1. 那条线是无端令人费解的。一般形式

   a? true : b
   

forboolean a, b等价于简单的

    a || b

1. 周围的否定和过多的括号使事情进一步复杂化。记住德摩根定律，这是一个微不足道的观察，这段代码相当于

   if (!_ok && Math.random() <= 0.1)
   

   return res;

2. 最初引入这个逻辑的提交有

   if (_ok == true) {
   

   _logger.log( Level.WARNING , “Server seen down: ” + _addr, e );
   } else if (Math.random() < 0.1) {
   _logger.log( Level.WARNING , “Server seen down: ” + _addr );
   }

‘ 另一个不称职的编码示例，但请注意 相反的逻辑 ：此处，如果有任何一种情况_ok或在 10% 的其他情况下，则记录事件，而 2. 中的代码
返回 10% 的时间并记录 90% 的时间。所以后来的提交不仅破坏了清晰度，而且破坏了正确性本身。

我认为在您发布的代码中，我们实际上可以看到作者打算如何将原件以某种方式从字面上转换为早期条件if- then所需的否定。return但后来他搞砸了，通过反转不等号插入了一个有效的“双重否定”。

1. 撇开编码风格问题不谈，随机日志本身就是一种非常可疑的做法，尤其是因为日志条目没有记录其自身的特殊行为。显然，其目的是减少对同一事实的重述：服务器当前已关闭。适当的解决方案是只记录服务器状态的 变化 ，而不是每个观察结果，更不用说随机选择 10% 的观察结果。是的，这需要更多的努力，所以让我们看看。

我只能希望所有这些从 仅检查三行代码 中积累的无能证据并不能公平地说明整个项目，并且这项工作将尽快得到清理。