Question

当我在使用C＃中的一些旧代码时，我遇到了一个令我烦恼的代码。

没有太多的麻烦，它就是这样的：

private string foo(string _text)
{
   /* some manipulation on _text */
   return _text = Server.HtmlDecode(_text);
}

这是让我烦恼的最后一句话;我来自C背景，我可以理解代码实际上是试图返回一个已解码的_text变量。赋值运算符的值也是左操作数，所以我可以看到它。

然而我仍觉得它很烦人。

我需要习惯于在C＃中进行纵向练习吗？

对我而言，最后一行应该只是

return Server.HtmlDecode(_text);

而不是作业表达。是否有更深入的C＃功能，我不知道？

Answer 1

当我在使用C＃中的一些旧代码时，我遇到了一个令我烦恼的代码。

这里有许多令人厌烦的问题。让我们列出所有。

private string foo(string _text)
{
   /* some manipulation on _text */
   return _text = Server.HtmlDecode(_text);
}

这是让我烦恼的最后一行

评论也令人厌烦。局部变量便宜。无需删除_text的原始值。相反，创建一个新的局部变量并操纵它。这样，当您在方法中的任何位置调试时，您可以知道原始参数是什么。（请记住，在变量被覆盖的那一刻，原始参数可能有资格进行垃圾收集，因此可能永远丢失。）

如果没有充分的理由，请不要写一个正式的参数。这使得调试变得更加困难。

赋值运算符的值是左操作数，所以我可以看到它。

在这种情况下这是正确的，但总的来说是微不足道的; C＃中赋值运算符的值是转换为与左侧相关联的类型右操作数后的值。请记住，左侧可能没有值;它可能是一个只写属性。

我需要习惯于在C＃中进行纵向练习吗？

这里有一个标准做法，是的。这种用法的奇怪之处在于：（1）选择的变量是形式的，（2）赋值与return组合。

C＃中的标准做法是：

string decoded = Server.HtmlDecode(_text);
return decoded;

现在你可能想知道这对你的建议有什么好处：

return Server.HtmlDecode(_text);

答案是：在Visual Studio 2013之前，调试器中没有工具来检查方法调用的返回值！因此，如果您想在调试时查看HtmlDecode返回的值，您有以下选择：

由于前三个是可怕的，而最后一个很容易，这就是许多C＃程序员习惯做的事情。

如果你这样做，然后不使用结果本地，那么C＃编译器知道这是一种常见的做法，故意压制“你写给当地人然后从未读过”警告。如果本地写了一个常量，它只会发出警告，在这种情况下，你已经知道它在编译时是什么，通常不需要在调试器中检查它。

希望现在VS2013最终支持这种频繁请求的功能，这种模式将逐渐消失。

Answer 2

此声明是多余的，不是C＃练习。

在ReSharper处于活动状态时这样做也会发出警告

分配的值未在任何执行路径中使用

如您所述，此代码确实是最佳实践

return Server.HtmlDecode(_text);

此外，由于解码是_text上操作的一部分，因此将assignated和return语句分开也是有效的，以便将逻辑保存在同一个块中：

/* Other manipulations on _text */
_text = Server.HtmlDecode(_text);

return _text;

Answer 3

不，这是一个愚蠢的事情，并且它牺牲了可读性的名义，将更多的代码塞进一行。这几乎总是一件坏事。

在这种情况下，它实际上没有任何意义。 _text是方法的参数，在方法体中更改它不会完成任何操作。传递给方法的字符串不会被修改。

Answer 4

他们有相同的结果。最常见的是看后者，或者：

_text = Server.HtmlDecode(_text);
return _text;

（我喜欢上述或return Server.HtmlDecode(_text);，但不喜欢你正在阅读的代码中的方式）

Answer 5

不，在这种情况下没有更深入的C＃功能，在return语句中进行分配毫无意义。它只会让你更难理解代码应该做的事情。

与你提出的建议的唯一区别在于，解码后的值被赋值给_text变量，但由于该变量不再使用，因此当方法结束时它的值是什么并不重要。该参数是方法内部的局部变量，不会影响方法之外的任何内容。