Question

让我从现实生活中的例子开始：

客户： Alex，在第138行的RemovalProcessor中发现了一些奇怪的东西：
if (Session.Handler.ExecutePrefetchTasks()==null); 
  Session.ExecuteDelayedQueries(); 
“if”后面的半圆是否应该在那里？

我：   哎呀......我会把它发给我们的家伙检查，但很可能，你是对的。

虽然案件很少见，但我承认几乎所有大项目都有类似的问题。

我知道C＃中的分号（和语句块）使用规则无法更改（我个人更喜欢Python风格）。但我认为用if语句识别完全符合的情况是个好主意，并将其归类为错误或警告。

我想到的几个Q / A：

为什么在这种情况下应该生成警告或错误？

因为这是开发人员的错误概率可能是99％。
为什么在这种情况下错误更可取？

在许多情况下，开发人员会忽略警告。

我明白这是他们自己的问题，并且有/ warnaserror （威胁警告为错误）切换，但由于这是一个错误具有很高的概率，如果不是错误（真的吗？;）），解决这个问题很容易，对这个案例进行分类可能会更好作为一个错误。

最后，这种情况下的错误不会“限制”开发人员，因为这样的代码可以（并且可能，必须）总是被重写没有if声明。
为什么在这种情况下警告更可取？

这不会破坏兼容性;我还怀疑一些代码生成器可以根据当前行为生成代码。

所以我很高兴听到你对此的看法。

Answer 1

它已经发出警告：

Possible mistaken empty statement

我同意你的观点，错误本来是可取的（如果你真的想要一个空语句，总是可以把它写成{ }，这更明确） - 但它们不会改变C＃语言通过这种方式。这将是一个突破性的变化，我怀疑他们（阅读：Eric Lippert的）理由是“利益不会超过成本”。

Answer 2

此示例与您的示例类似，不应产生编译错误，因为它的目的是有条件地执行逻辑。

if ( DoSomething() || SolveEquation() ) ;  // Intentional - compiles and  runs as expected.

如果删除if关键字，则会出现编译错误。

DoSomething() || SolveEquation();  // Compile ERROR.

C＃的{p> Short circuit logic确定：如果DoSomething（）返回true，则不评估SolveEquation（）;否则就会被评估。

我们假设两个函数都以某种方式改变了正在运行的程序的状态，因此执行哪个函数很重要 - 因为这将决定一种特定类型的程序状态。当然，写它的更好方法是......

if ( ! DoSomething() )
    SolveEquation();

或（感谢Alex来自评论中的这个）

bool result = DoSomething() || SolveEquation();

..但为什么抢劫用户的第一种方式？

因为第一种方式可以被认为是不好的形式，但它证明你不一定希望这种情况产生编译错误。

这是我的论点，它不应该产生编译错误。现有的警告是好的，以防开发人员犯了一个常见的错误。

应该在C＃中清空“if”语句导致错误或警告？

2 个答案: