SonarLint - 关于 VB.NET 的一些规则的问题

SonarLint - questions about some of the rules for VB.NET

我在 Java 中遇到的绝大多数 SonarLint 规则似乎都是合理且合理的。然而,自从我开始为 VB.NET 使用 SonarLint 以来,我遇到了一些规则,这些规则让我质疑它们的用处,甚至质疑它们是否正常工作。

我想知道这是否只是我以次优方式使用某些 VB.NET 构造的问题,或者规则是否真的存在缺陷。 (抱歉,如果这个问题有点长。我不知道是否应该为每个单独的规则创建一个单独的问题。)

我发现以下规则会留下一些未考虑的情况,这些情况实际上会变成误报:

以下规则我不太确定:

感谢您提出这些观点。请注意,并非所有规则都适用。在某些情况下,我们需要在错误的 positives/false negatives/real 情况之间进行平衡。例如,在运算符规则的两边都有相同的表达式。具有相同的操作数是错误吗?不,这不对。如果是,那么编译器会报告它。难闻的气味,通常是错误的吗?在很多情况下是的。例如,请参阅 Roslyn。我们是否应该调整此规则以排除某些情况?是的,我们应该,2 << 2 没有错。因此,需要进行很多平衡,我们尝试满足为用户带来最大价值的实现。

对于您提出的点数:

  • 相同条件结构中的两个分支不应具有完全相同的实现

这条规则通常指出两个代码块完全匹配是一个不好的迹象。出于多种原因,应该避免复制粘贴代码,例如,如果您需要在一个地方修复代码,那么您也需要在另一个地方修复它。你是对的,添加否定条件会是一团糟,但如果你将每个条件提取到它自己的方法中(并调用其中的否定方法)并使用适当的名称,那么它可能会提高代码的可读性。

对于Select Case,同样,复制粘贴代码总是一个坏兆头。在这种情况下,您可以这样做:

Select Case i
  ...
  Case 0 To 40
  Case Else
    value = 0 ' Compliant
End Select

或者干脆去掉 0-40 的大小写。

  • 二元运算符的两边不应使用相同的表达式

我认为这是一个极端案例。见答案第一段

  • "Exit" 不应使用语句

几乎总是正确的是,通过选择另一种循环类型或更改停止条件,您可以在不使用任何 "Exit" 语句的情况下逃脱。最好从循环中设置一个出口点。

  • 有符号类型应该优先于无符号类型

这是 SonarQube VB.NET 的遗留规则,我同意你的看法,它不应该在 SonarLint 中默认启用。我在我们的 JIRA 中创建了以下票证:https://jira.sonarsource.com/browse/SLVS-1074

  • 应该使用数组字面量而不是数组创建表达式

是的,这似乎是误报,我们不应该在明确指定大小时报告数组创建。 https://jira.sonarsource.com/browse/SLVS-1075