Question

我负责在组织内创建编码标准并进行代码审查。

我在源代码中遇到了这样的内容：

object.Property = myVar1 = myVar2;

我个人并不这样做，因为我觉得这令人困惑。我看到这个，我想这样读：

object.Property = myVar1 == myVar2;

现在我知道它在做什么：它将myVar分配给myVar2，然后将object.Property分配给myVar2。编码标准文档没有明确说明您是否可以这样做。但它确实声明不在if语句中分配变量。

我想我的问题是，作为一种编码练习而不是这样做是不是很糟糕？我不喜欢制定代码标准政策“仅仅因为我这么说”

编辑以更好地解释我的理解

Answer 1

我总是在括号中包含等式表达式：

object.Property = (myVar1 == myVar2);

这引起了人们的注意，这不是一项任务。

Answer 2

这种所谓的“链式任务”确实存在争议，而且有很多问题可以解决这个问题。

正如你所知，这是作为表达而不是陈述的作业的副产品，对很多人来说，它可能会令人困惑。

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

a = b = []

使a和b引用相同的对象。新手倾向于认为它创建了两个独立的空数组，可以独立填充。不是这样！ C＃等价物，

a = b = new SomethingOrOther();

可能发生的可能性要小得多，因为a和b更有可能在声明时初始化，而这样的双赋值会更少见此外，在这种情况下，C＃程序员更有可能看到明显的共享。

制定禁止此行为的一个很好的理由是三方面的：

完全没必要。
容易出错（如上面的数组示例中所示）。

当您遇到容易出错的构造时，您应该避免使用它们，因为在避免它们时，您将永远不会发生该特定错误。当然，在C＃中，它可能比其他语言更不容易出错。

Answer 3

在C＃中，（通常）无需担心。

除非你的变量是bool（在这种情况下你应该把它分成两个语句），不容易出错 - 只有两个中的一个会永远工作正常，所以没有“意外”省略或输入额外=的危险。

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

Answer 4

首先，对你不赞成“我的方式是正确的方式”的称赞。这类问题非常主观，开发人员会有不同的（通常是强烈的）意见。

我会说我试图避免混淆代码，但是这样的语句可以（在某些情况下）通过将大量语句折叠成更少的语句来使代码更具可读性。并非总是如此，但我认为有时候会这样。

我的意见不是要在您的编码标准中排除这种声明，而是尽量包含不同的编码风格（除了明显不可读或令人困惑的代码）。

我参与了比我想要的更多“编码标准”讨论，我发现它们往往比他们想要解决的问题引起更多的摩擦。

Answer 5

由于我经常遇到想要 a = b = c 很少，我只是把它写成两个单独的语句。（这通常也适合我，因为我喜欢在可能的情况下不重新分配变量，仅在声明中进行赋值，并且我只为每个变量声明声明一个变量。）

然后，如果我做遇到a = b == c我就把它当作“将平等的结果分配给一个”，甚至不要三思而后行（作为我的编码风格不包括a = b = c）。

但是，这个错误在C＃中被最小化，因为除了处理布尔类型（对于a，b，和 c），编译器会抱怨，因为类型将是错误的。

快乐的编码。

Answer 6

现在我知道它在做什么：它将myVar分配给myVar2，然后将object.Property分配给myVar1

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

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

object.Property = myVar1 == myVar2;

Answer 7

由于这是关于编码风格，这是非常恕我直言

根据开发人员的不同，几乎任何语言功能都可能被视为令人困惑或精彩。有些人认为运算符重载（或泛型，闭包，高阶函数等）是通往地狱的道路，其他人认为它是创建succint和可读代码的好工具。

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

如果在您的代码库中这是一种不常见的模式，那么可能是一个令人困惑的模式，因此最好建议反对并搜索使用此模式的地方并考虑重构。< / p>

a = b = c编码标准

7 个答案: