A = b = c编码标准

object.Property = myVar1 = myVar2;

object.Property = myVar1 == myVar2;

我总是将等式表达式括在括号中:

object.Property = (myVar1 == myVar2);

这让我们注意到它不是赋值。

这个所谓的"链式赋值"确实是有争议的，有很多关于SO的问题。

它是赋值作为表达式而不是语句的副产品，正如你所知道的，对于许多人来说，它可能会令人困惑。

在许多语言中，这对新手来说有些危险。在[]是空数组对象的构造函数的语言中，写

a = b = []

使得a和b引用同一个对象。新手倾向于认为它创建了两个可以独立填充的空数组。不是这样的!c#的等效符

a = b = new SomethingOrOther();

是不太可能发生的，因为a和b更有可能在声明点初始化，而这样的双赋值将是罕见的，而且c#程序员更有可能在这种情况下看到明显的共享。

禁止这样做的一个很好的理由有三点:

这是完全没有必要的。
1. 它很容易出错(就像上面的数组例子一样)。

当您遇到容易出错的结构时，应该避免它们，因为避免它们，您将永远不会犯那个特定的错误。当然，在c#中，它可能比在其他语言中更不容易出错。

在c#中，这(通常)没什么好担心的。

除非你的变量是bool(在这种情况下，你应该把它分成两个语句)，否则是不容易出错的——两个语句中只有一个会正确工作，所以没有"意外"遗漏或输入额外的=的危险。

结论:不要担心非布尔情况。

首先，感谢你没有假设"我的方法就是正确的方法"。这类问题是非常主观的，开发者会有不同的(通常是强烈的)观点。

我会说我尽量避免混淆代码，但是这样的语句可以(在某些情况下)通过将大量语句折叠成更少的语句使代码更具可读性。不总是正确的，但我认为有时是正确的。

我的意见是不要在你的编码标准中排除这种语句，并尝试尽可能地包含不同的编码风格(除了明显不可读或令人困惑的代码)。

我已经参与了很多"编码标准"的讨论，我发现它们往往会引起更多的摩擦，而不是它们想要解决的问题。

由于我经常遇到我想要 a = b = c 很少的时候，我只是把它写成两个单独的语句。(这通常对我来说也很好，因为我喜欢在可能的情况下不给变量重新赋值，只在声明中赋值，并且每个变量声明只声明一个变量。)

然后，如果我做遇到a = b == c我只是把它作为"分配相等的结果给a"，甚至不考虑它(因为我的编码风格不包括a = b = c)。

然而，这个错误在c#中被最小化，因为除了处理布尔类型(对于a, b， 和 C)之外，编译器会因为类型错误而报错。

幸福的编码。

现在我知道它在做什么了:它把myVar赋值给myVar2，然后是object。属性myVar1

你的理解是不正确的，编译器不会这样做。因为assignment expressions返回一个值，因此，在您的示例中，object.Property被赋值为赋值表达式myVar1 = myVar2的返回值。NOT将myVar2分配给myVar1，再将myVar1分配给object.Property

所以，你给出的两个陈述之间没有混淆。但是，如果变量不具有相同的类型，则应该使用括号来使代码可读。

object.Property = myVar1 == myVar2;

由于这是关于编码风格的，这是非常重要的

几乎所有的语言特性都可以被看作是令人困惑的或美妙的，这取决于开发人员。有些人认为操作符重载(或泛型、闭包、高阶函数等)是通往地狱之路，另一些人则认为它是创建简洁易读代码的好工具。

如果这是您的代码库中的常见模式，那么您的开发人员很可能对该模式的语义感到满意。在这种情况下，我认为反对它的建议可能会适得其反。

如果它在您的代码库中是一个不常见的模式，那么可能是一个令人困惑的模式，因此建议不要使用它，并搜索使用该模式的地方并考虑重构。