C# 是否存在foo=foo有意义的有效情况？

在我继承的

C#

项目中清除了一些警告后，我发现了以下代码片段：

private bool _WriteValue(object FieldValue,..,..)
  ...
  if(MultipFactor!=1)
     FieldValue=((double)FieldValue)*MultipFactor;
  else
    FieldValue=FieldValue;

我显然已经烧掉了

else

块，没有考虑太多，只是想知道为什么以前的程序员已经离开了这个部分

• 是不是因为太懒而删除了它
• 对于一些未来的程序员来说，保存一些输入以防发生特定的更改，这是一种礼貌吗
• 它隐藏着什么危险的东西吗

在您看来，是否有任何有效的情况下

foo=foo

是有意义的

---

有关

\u WriteValue

方法的更多详细信息：

---

\u WriteValue

方法被包装成不同的重载

WriteValue

方法，这些方法传递给

对象字段值

参数，以下类型的值：

int

，

long

，

字符串

和

Datetime

有一些糟糕的程序员，而且它们通常会留下一些垃圾…

如果

FieldValue

是一个属性，那么

set

操作符可能会触发一些代码，因此在这种情况下，自我赋值是有意义的

例如：

public string FieldValue
{
    get
    {
        return _fieldValue;
    }
    set
    {
        _fieldValue = value;
        Trace.WriteLine( string.Format("Received value '{0}'.", value ) );
    }
}

---

（我的答案是在海报添加了代码< FieldValue > <代码>实际上是一个方法参数，而不是我假设的一个属性）

< p> C++中你可以定义“代码>运算符=< /C> >做你想做的任何事情：）< /P> < P>如果在代码< FieldValue >代码后面有一个吸气剂或一个设置器，那么它可能会有副作用。例如：

private double myFieldValue;

public double FieldValue
{
    get { return myFieldValue; }
    set { myFieldValue = value; ReformatSystemVolume(); }
}

---

有副作用的吸气剂是非常糟糕的做法。然而，二传者广泛的副作用是很常见的，尽管这些副作用不像我的例子中那样剧烈，但不太常见

程序员可能不知道条件断点的存在，并利用该语句作为放置条件触发的断点的位置

---

我只是想说清楚，我并不是说这是一个好主意，但在没有条件断点的环境中，这是一个技巧。

在一些低级硬件情况下，设置值会产生（理想的）副作用，其他方式无法调用。这很愚蠢，但超出了程序员的范围。我只在裸C代码中看到过这种情况，所以我确信这不是为什么你在C代码中看到这种情况，但它确实发生了。

请注意，这是一个非常好（而且非常常见）的例子，说明你应该评论的事情：任何“明显的”修复实际上会破坏东西的地方。确保你从挫折中学习

但这会打开一个蠕虫的罐子，对财产有副作用，哇！任何人在不知道这些副作用是什么的情况下阅读它都是毫无意义的。@Mr.Yes，我同意，我只是在猜测一个使用场景：-）@SystemPuntoo不确定。请注意，我的回答是对你的文章的，在你添加信息之前，

FieldValue

实际上是一个方法参数，而不是我首先假设的属性。在C#中，你不能，至少对于赋值运算符不能。在C++中，只有一元、二元和关系运算符可以重载。C++在哪里出现这个问题？也许代码是从C++移植的，因此从原来的复制到=操作符被重载的地方。因此，如果是这样的话，功能可能实际上被破坏了。Fieldvalue的属性设置程序有任何副作用吗？如果是我，我只需去掉

if

，然后每次都进行乘法！你是在建议我评论我已经删除了

else

块吗？对不起，我的意思是，不管是谁写的，还是你找到了它存在的合法原因。我的观点是，如果你曾经做过类似的事情，记住这一集，让你的同事或未来的自己免受同样的痛苦！