命名约定是否可以使代码变得更好维护？
我喜欢给我的变量、方法和对象起描述性的名称。显然没有太过分，但让我举几个例子。
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)
{
}
可读性下降了。总是存在智能感知的争论，只需将鼠标悬停在变量上即可查看它们是什么类型，或者它们是什么。 可读的代码，使代码易于理解。
命名约定是否可以使代码变得更好维护？
I like to give my variables, methods and objects descriptive names. Obviously not going overboard, but let me give you a couple of examples.
public class Account
{
public decimal Balance { get; set; }
}
Account account = new Account();
account.Balance = 1000;
Some people would opt to go for the following, which really does not make sense to me, unless you are a lazy typist.
Account acc = new Account();
acc.Balance = 1000;
The problem is when you have logic with these abbreviations. You get extremely confused as to what is happening.
Imagine the following objects.
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)
{
}
The readability goes down the drain. There is always the argument of intellisense and just hovering over your variables to see what type they are, or what they are.
Readable code, makes for easily understandable code.
Does naming conventions make better maintainable code?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，当然，命名约定可以使代码变得更好维护。
这就是为什么，在你第一天上编程课时，如果你调用变量 x 或 i...，讲师会打你。
你必须记住，变量/方法/类等的名称纯粹是为程序员准备的，因为编译时这些只是内存地址。
你必须尝试在可读、不言自明的命名约定、良好的注释和结构良好的代码之间取得良好的平衡，以编写更好的可维护代码。
Yes, of course naming conventions make better maintainable code.
That is why, in your first day in a programming class, the lecturer will smack you if you call a variable x, or i...
You have to remember that names of variables/methods/class, etc is purely for the programmer, as when compiled these will only be addresses to memory.
you have to try and use a good balance of readable, self explanitory naming conventions, good comments and well structured code to make better maintainable code.
是的，对于任何没有非常有限范围的变量。
当变量的范围非常有限，并且代码围绕该变量时，您可以使用一次性的变量名称。
例如，如果循环体很小并且计数器不具有任何其他含义，则循环中的计数器可以具有简单的名称：
使用短名称可以使 Lambda 表达式更具可读性：
但是，使用短名称时，不要这样做不要尝试缩写某些东西。如果单个字母或众所周知的缩写不能做到这一点，您也可以选择更长的名称。
例如，使用
n作为数值（如上面的 lambda 表达式所示）即可。使用更长但仍然是缩写的名称，例如itnum或itmid会使名称包含更多信息，但不足以发挥作用，因此itemNumber或者itemId会更好。Yes, for any variable that doesn't have a very limited scope.
When the scope of a variable is very limited, and when the code revolves around that variable, you can get away with a throw-away variable name.
For example, a counter in a loop can have a simple name if the loop body is small and the counter doesn't rellay have any other meaning:
Lambda expressions can be more readable using a short name:
However, when using short names don't try to abbreviate something. If a single letter or a well known abbreviation doesn't do it, you can just as well go for a longer name.
For example, using
nfor a numeric value, as in the lambda exression above, would work. Using something longer that is still an abbreviation, likeitnumoritmidmakes the name carry more information, but not enough to be useful, soitemNumberoritemIdwould be better.当我使用 C# 等语言进行编程时，我经常会给变量起一个短名称，因为这样更容易输入，并且可以在屏幕上显示更多代码。当您处于该区域并且确切地知道一切是什么时，这种方法很有效，但是由于您提到的原因，对于局外人甚至几个小时后的您自己来说，这都会非常令人困惑。好的 IDE 使重命名变量变得非常容易，我绝对建议在离开项目过夜之前或者在共享项目之前这样做。
Guffa 提出了一些关于短变量名何时合适的好观点。
When I program in languages like C#, I'll often give my variables short names just because it's easier to type and I can fit more code on the screen. This works well when you're in the zone and know exactly what everything is, but for exactly the reasons you mentioned, it would be very confusing to an outsider, or even yourself a few hours later. Nice IDE's make it super easy to rename variables, which I would definitely suggest doing before walking away from your project for the night, or certainly before sharing it.
Guffa raises some good points about when short variable names are appropriate.