命名约定是否可以使代码变得更好维护？

Question

我喜欢给我的变量、方法和对象起描述性的名称。显然没有太过分，但让我举几个例子。

public class Account
{
    public decimal Balance { get; set; }
}

Account account = new Account();
account.Balance = 1000;

有些人会选择以下内容，这对我来说确实没有意义，除非你是一个懒惰的打字员。

Account acc = new Account();
acc.Balance = 1000;

问题是当你对这些缩写有逻辑时。你对正在发生的事情感到非常困惑。

想象以下物体。

public class Account { public DebitOrder DebitOrder { get; set; } }
public class DebitOrder { BankDetail BankDetail { get; set; } }
public class BankDetail {}

Account acc = new Account();
DebitOrder do = new DebitOrder();
BankDetail bd = new BankDetail();

if(acc.DebitOrder.SomeProperty == do.SomeProperty)
{

}

可读性下降了。总是存在智能感知的争论，只需将鼠标悬停在变量上即可查看它们是什么类型，或者它们是什么。可读的代码，使代码易于理解。

命名约定是否可以使代码变得更好维护？

Answer 1

是的, 当然，命名约定可以使代码变得更好维护。

这就是为什么，在你第一天上编程课时，如果你调用变量 x 或 i...，讲师就会打你。

您必须记住，变量/方法/类等的名称纯粹是针对程序员的，因为编译时这些只是内存地址。

你必须尝试在可读、不言自明的命名约定、良好的注释和结构良好的代码之间取得良好的平衡，以编写更好的可维护代码。

Answer 2

是的，对于任何没有非常有限范围的变量。

当变量的范围非常有限，并且当代码围绕该变量展开时，您可以使用一个抛出的变量名称。

例如，如果循环主体较小，并且柜台没有其他含义，则循环中的计数器可以具有简单的名称：

for (int i = 0; i < 10; i++) arr[i] = 0;

Lambda表达式可以使用一个简短名称更可读性：

var items = source.Select(n => n.ToString() + ".");

但是，当使用短名称时，不要试图缩写某些东西。如果单个字母或众所周知的缩写不这样做，那么您也可以再说一个更长的名字。

例如，使用 n 对于像上面的lambda外出一样，对于数字值，将有效。使用更长的东西仍然是缩写，例如 itnum 或者 itmid 使该名称携带更多信息，但不足以有用，因此 itemNumber 或者 itemId 会更好。

Answer 3

当我用C＃等语言编程时，我通常会给我的变量简短名称仅仅是因为它易于键入，并且可以在屏幕上安装更多代码。当您进入该区域并确切地知道一切是什么时，这很好，但是由于您提到的原因，这会使局外人甚至几个小时后都感到困惑。 Nice Ide's使重命名变量非常容易，我肯定会建议您在夜晚或在分享之前肯定地走出您的项目之前做。

Guffa提出了一些何时合适的变量名称。