C# 条件表达式中的赋值-这可能对代码质量产生什么影响？

在对其中一个项目进行代码检查时，我发现Resharper对类似以下代码块发出了“条件表达式中的赋值”警告：

if (this.pnlSummary.Visible = isValid)
{
    //do something
}
else
{
    // do something
}

虽然我同意这在某种程度上损害了可读性。。但除此之外，就代码执行而言，我不认为使用它有任何缺点

有谁能建议一下用条件表达式写作业的潜在后果是什么

基于此，我将指导开发人员避免编写此类代码

---

任何关于这方面的建议都将不胜感激。

一个好的程序员是编写同事理解的代码的程序员，而不是编写计算机理解的代码的程序员。

虽然我同意这在某种程度上损害了可读性

给你。这绝对是阻止程序员这样编写代码的一个很好的理由。 另外，当你只需几次击键就能写出更好的代码时，那么做一些有害的事情背后的原因是什么

this.pnlSummary.Visible = isValid;
if (this.pnlSummary.Visible)
{
    //do something
}
else
{ 
   // do something
}

---

看到了吗？只有一些钥匙和几个点。自动完成是了不起的

我认为这会影响可读性，但不是“我想知道那段代码是做什么的？”，而是“这很可能是赋值错误，而不是比较错误，我会花一些时间来检查它”。静态代码分析工具，如R#也总是会在这方面给出误报。

我想说，您已经知道问题是什么，可读性。期望是你在写一个比较，它毕竟是一个if语句，但结果是你也在做一个赋值，所以检查某个东西的东西也变成了改变某个东西的东西。这不是预期的，它肯定会导致更长的故障排除会话。此外，如果一个为警告潜在的坏代码而构建的工具警告您某些代码，那么（通常）您应该有一个非常好的理由告诉该工具闭嘴，而不是实际修复它。现在，一旦您知道代码的作用，这实际上会做其他事情吗？我的意思是，现在我们知道它实际上做了一个赋值，然后也对赋值的值起作用，它会不会表现得很奇怪，比如走错了分支？不，不会的。除非出现一些奇怪的编译器错误，否则这将表现为“预期”。我引用这句话是因为现在我们希望它能完成一项任务。基本上，你是在询问人们的想法，所以投票决定是否关闭它是基于意见。一般来说，你应该指导开发人员避免编写产生警告的代码。在你开始要求该工具（编译器、visual studio、resharper等）停止抱怨某件事之前，同样，你应该有一个非常好的理由这样做。如果你在某个时候，绝对必须编写某个工具抱怨的代码，写一条注释，确保出现的下一个程序员都看到了问题，并且知道这不是一个应该“修复”的问题。我没有说你抱怨这个工具：）我说你试图找到理由忽略这个工具抱怨的内容：）我现在明白了，你正在寻找理由，你可以回到你的开发人员那里，回到这样一个事实，即这样的代码（可能）不应该被编写，但在这方面，我仍然坚持我以前的观点。开发人员应该有很好的理由这样写，如果他们不这样写，那就足够了。如果我之前的评论听起来很刺耳，我很抱歉，这根本不是我的本意。但就我个人而言，如果（isValid），我会写

。我甚至会考虑将任务转移到相应的分支中，使面板的可见性取决于是否有效，这大概更清楚，这两个分支中的其他代码也取决于事情是否有效。我认为逻辑是基于面板的可见性。isValid和面板的可见性现在耦合在一起，但将来可能有人更改代码并删除行
this.pnlSummary.Visible=isValid。并将其更改为
this.pnlSummary.Visible=isValid2