SonarQube说以下操作是错误的:
@Override
public boolean android.os.Handler.Callback.handleMessage(Message msg)
{
super.handleMessage(msg);
Object obj = getXY();
if (obj == null) { return true; }
...
...
...
...
...
...
return true;
}
当一个方法被设计为返回一个不变值时，它可能很差设计，但它不应该对程序的结果产生不利影响。然而，当它发生在逻辑的所有路径上时，它肯定是bug。
当方法包含多个返回值时，该规则会引发问题返回相同值的语句
我不认为这个警告在这种情况下是正确的，你认为呢?你会有不同的方法吗?
嗯，
当一个方法包含几个返回相同值的返回语句时，该规则会引发一个问题。
Sonar报告它抱怨所有返回语句具有相同的返回值。您的代码确实包含(至少)两个这样的语句:
if (obj == null) { return true }
...
return true;
我想你在这里漏了一个分号，但那是另一回事。
你至少可以这样写:
if (obj != null) {
...
}
return true;
现在看看投诉是否消失了。如果它不消失，你也无能为力。正如Federico已经在评论中指出的，Sonar是一个非常好的工具，但它不是圣杯。在某些情况下，你必须告诉Sonar这是唯一的方法。
关于一些评论说你应该将返回类型更改为void-我会建议你同样，但你不能这样做，或者当然，如果你从超类型重写。(我假设你在这里重写android.os.Handler.Callback.handleMessage(Message))。
TL;DR您是负责开发的，SonarCube是您的助手。你做决定，但至少听听你助理的意见是个好主意。
每当有人(SonarCube)试图将典型的编程错误形式化为检测规则时，就会出现误报，即规则匹配，但代码正常的情况。
在你的例子中，"典型的编程错误"例如，编写一个布尔返回方法，其结果应该取决于某些参数，但您错误地总是返回相同的值。这样的错误时有发生。
警告意味着SonarCube发现了可疑代码，您应该查看源代码片段，并确定是否存在错误。SonarCube给出了有价值的提示。你应该认真对待这些暗示，试着理解它们所涉及的问题。在许多情况下，这些提示实际上表明了一个错误、一个设计缺陷或糟糕的风格。但如果不是(由您决定)，请保持代码不变。
回到你的例子:如果这里总是返回true并且有一些早期返回语句，并且坚持你的风格指南，你应该告诉SonarCube(但其他人必须回答如何做到这一点，也许使用@SuppressWarnings注释)。
其他人建议更改代码，用嵌套条件替换早期返回(假设该方法将传递SonarCube)，但我不建议这样做:
- 它偏离了你似乎习惯的编程风格。 这样的重构意味着引入新错误的风险。人类并不擅长理解复杂的条件，所以在这个过程中很容易把事情搞砸。
这里的标志不代表任何东西，因为它总是为真。什么时候会是假的。如果你想执行一些基于对象是否为null的逻辑，那么最好让方法返回void并编写一些像这样的逻辑。接口或抽象类是你自己的吗只有在这种情况下，标志只是一种形式那么我建议改变接口或抽象类中的方法，使方法返回void并在实现中执行如下操作
@Override
public void handleMessage(Message msg)
{
super.handleMessage(msg);
Object obj = getXY();
if (obj != null) {
...
...
...
...
...
...
}
}