短变量名有借口吗？

对于我目前正在使用的代码库，这已经变得非常沮丧。我们的许多变量名都很简短且没有描述性。我是该项目上剩下的唯一一名开发人员，并且没有关于它们大多数功能的文档，因此我不得不花更多的时间来跟踪它们的含义。

例如，我正在阅读一些更新光学表面定义的代码。开始时设置的变量如下：

double dR, dCV, dK, dDin, dDout, dRin, dRout
dR = Convert.ToDouble(_tblAsphere.Rows[0].ItemArray.GetValue(1));
dCV = convert.ToDouble(_tblAsphere.Rows[1].ItemArray.GetValue(1));
... and so on

也许只是我一个人，但实际上它们告诉我的内容并没有告诉我，这使得进一步理解代码变得困难。我所知道的是，它是一个变量，该变量从某个地方的特定表中解析出特定行。经过一番搜索，我发现了它们的含义：

dR = radius
dCV = curvature
dK = conic constant
dDin = inner aperture
dDout = outer aperture
dRin = inner radius
dRout = outer radius

我将它们重命名为基本上我在那里所拥有的。它延长了一些行，但是我觉得这是一个公平的权衡。但是，在许多代码中都使用了这种命名方案。我不确定这是来自开发人员的作品，他们是通过使用较旧的系统而学习的，还是背后有更深层的原因。是否有充分的理由以这种方式命名变量，还是我在遇到变量时将其更新为更具描述性的名称是否合理？

这些变量名称似乎是基于您期望在物理学教科书中找到的有关各种光学问题的缩写。这是短变量名通常优于长变量名的情况之一。如果您有习惯使用Rin，Rout等常用缩写的物理学家（或习惯于手工求解方程式的人员），则使用这些缩写的代码将比使用较长的变量名的代码更清晰。它还使将论文和教科书中的公式与代码进行比较变得容易得多，以确保代码实际上在正确地进行计算。

任何熟悉光学的人都会立即识别出Rin作为内半径（在物理学论文中，in将其表示为下标），Rout视为外半径等。尽管他们几乎可以肯定地能够在心理上翻译某些东西就像innerRadius更熟悉的命名法一样，这样做会使该代码对那个人不太清楚。这将使得发现熟悉的公式被错误编码的情况变得更加困难，并且使得将代码中的方程式与在纸张或教科书中找到的方程式进行相互转换也变得更加困难。

如果您是唯一查看此代码的人，则无需在代码与标准光学方程式之间进行转换，物理学家不太可能将来需要查看该代码，也许重构是有意义的，因为缩写的好处不再超过成本。但是，如果这是新的发展，几乎可以肯定的是，在代码中使用与文献中相同的缩写。

寿命短的变量应简短命名。举例来说，您无需编写for(int arrayCounter = 0; arrayCounter < 10; arrayCounter++) { ...。而是使用for(int i ...。

根据一般经验，可以说变量范围越短，名称应越短。循环计数器往往只有单个字母，说i，j和k。局部变量类似baseor或fromand to。例如，全局变量在某种程度上更加精细EntityTablePointer。

您使用的代码库可能未遵循这样的规则。这是进行一些重构的一个很好的理由！

代码的问题不是短名称，而是缺少注释（该注释可以解释缩写），或者指向一些有关导出变量的公式的有用材料。

该代码仅假设问题域熟悉。

很好，因为问题域的熟悉度可能是理解和维护代码所必需的，尤其是在“拥有”该代码的人的角色中，因此，您应该获得熟悉度，而不是四处张名。

但是，如果代码提供一些提示以用作跳板，那就太好了。即使是领域专家也可能忘记这dK是一个圆锥常数。在评论栏中添加一些“备忘单”不会有问题。

对于问题域中众所周知的某些变量（例如您在此处的情况），简洁的变量名是合理的。如果我正在开发游戏，则希望游戏实体具有位置变量x和y，而不是horizontalPosition和verticalPosition。同样没有超出索引任何语义的循环计数器，我希望看到i，j，k。

根据“清洁代码”：

变量名称应：

• 有意透露
• 避免虚假信息
• 做出有意义的区分
• 明显
• 可搜寻

异常是i,j,k,m,nfor循环中使用的谚语。

变量名称是您理所当然地抱怨的，上述都不做。这些名字是坏名字。

另外，由于每个方法都必须为short，因此请使用前缀指示不再使用作用域或类型。

这个名字更好：

radius
curvature
conicConstant
innerAperture
outerAperture
innerRadius
outerRadius

评论者说，使用长变量名会太复杂：

简短的变量名也不会让它变得简单：

fnZR = (r^2/fnR(1+Math.sqrt((1+k) * (r^2/R^2)))) + a[1]*r^2 + a[1]*r^4 + a[1]*r^6 ...;

答案是长名称和中间结果，直到最后得到以下内容：

thisNiceThing =  ( thisOKThing / thisGreatThing ) + thisAwsomeThing;

有两个很好的理由不重命名遗留代码中的变量。

（1）除非您使用自动重构工具，否则引入错误的可能性很高。因此，“如果没有损坏，请不要修复”

（2）您将比较当前版本与过去版本，以查看更改内容是不可能的。这将使以后的代码维护更加困难。

是否有充分的理由以这种方式命名变量，还是我在遇到变量时将其更新为更具描述性的名称是否合理？

使用较小名称的原因是，如果原始程序员发现它们更易于使用。大概他们有权发现这种情况，并且有权不拥有与您相同的个人喜好。就个人而言，我会发现...

dDin better than dDinnerAperture
dDout better than dDouterAperture

...如果我在长时间的复杂计算中使用它们。数学表达式越小，通常越容易一次看到整个事物。尽管是这种情况，但它们可能比dIn和dOut更好，因此没有重复的D可能导致简单的错字。

另一方面，如果您发现使用起来比较困难，则将自己淘汰，然后重命名为更长的形式。特别是如果您负责该代码。

通常，我认为这是应该遵循的规则，即您可以使用非常简短的变量名，因为您知道特定代码的“技术熟练”人员会立即理解该变量名的引用。（无论如何，对于这种情况，您总是会有注释），并且可以根据变量的使用方式来轻松地区分变量的本地化用法。

为了对此进行扩展，这意味着您不应该费力地混淆变量名，但是，可以对变量名使用缩写，在这种情况下，您知道只有了解代码基本概念的人员才有可能仍然要阅读它。

以一个真实的例子为例，最近，我正在创建一个Javascript类，该类将具有一定的纬度，并告诉您在给定日期所期望的日照量。

为了创建此日d类，我引用了六种资源（《天文学年鉴》）以及其他语言（PHP，Java，C等）的摘要。

在几乎所有这些词中，他们都使用相似的相同缩写，从表面上看绝对没有任何意义。

K，T，EPS，deltaPsi，eot，LM，RA

但是，如果您具有物理知识，则可以理解它们的本质。我不希望其他人接触到此代码，所以为什么要使用冗长的变量名？

julianTime，nutationOfEclipticalLongitudeExpressedInDegrees，equationOfTime，longitudeMean，rightAscension。

另外，很多时候，当变量名是暂时的时，也就是说，它们仅用于临时分配一些值，那么使用冗长的版本通常是没有意义的，尤其是在变量的上下文中解释它的目的。

绝对有；通常，短变量名是必需的。

就我而言，我在高级机器人学课程中进行航点导航，并且我们在KISS-C中对机器人进行编程。我们需要用于当前和目标（x，y）坐标，（x，y）距离，当前和目标航向以及转弯角度的变量。

特别是在x和y坐标的情况下，完全不需要长的变量名，并且诸如xC（当前x），yD（目标y）和pD（目标phi）的名称就足够了，并且最容易理解在这种情况下。

您可能会争辩说，这些不是程序员协议所规定的“描述性变量名”，但是由于名称是基于简单的代码（d =目标，c =当前），因此一开始就非常简单地说明了所有描述他们需要。

是否有充分的理由以这种方式命名变量，还是我在遇到变量时将其更新为更具描述性的名称是否合理？

通常，复杂的算法以matlab（或类似语言）实现。我看到的是人们只是接管了变量名称。这样，比较实现就很简单。

所有其他答案几乎都是正确的。这些缩写可以在数学和物理学中找到，除非它们不是以d（如您的示例）开头。以d开头的变量通常被命名为代表微分。

所有普通的编码指南都要求不要以第一个字母代表类型来命名变量（如您的情况），因为在所有现代IDE中浏览代码非常容易。

我可以想到变量名要简短的原因。

短名称易于使用较短的跨度阅读，因此注意范围短。

例如，一旦我习惯了svdb意味着“保存到数据库”这一事实，对源代码的扫描速度就会变好，因为我只需要快速扫描4个字符，而不是在读取SaveToDatabase时（14个字符，情况会变得更糟）。以获取更复杂的操作名称）。我说“扫描”而不是“读取”，因为这是分析源代码的主要部分。

在扫描大量源代码时，这可以提供良好的性能提升。

而且，它仅有助于懒惰的程序员在编写代码时键入这些短名称。

当然，所有这些“速记”都应该在源代码的某些标准位置列出。

以略有不同的方式来构造@zxcdw所说的内容，并在方法方面进行详细说明：

功能应该是纯净的，简短的并且完美地封装了某些功能：黑匣子逻辑，无论是否静置了40年，它都将继续执行其设计的工作，因为其接口（输入和输出）是声音，即使您对其内部一无所知。

这是您要编写的代码类型：这是持久的代码，易于移植。

必要时，可以从其他（内联）函数调用中组合函数，以保持代码的细粒度。

现在，使用适当的描述性函数名称（如有必要，请加上详细说明！），由于范围太小，我们可以最大程度地减少误解这些缩写变量名称的机会。

变量名应尽可能地具有描述性，以帮助提高程序的可读性。您自己亲身体验了：由于命名不佳，您很难确定程序的功能。

没有充分的理由不使用描述性名称。这将对您以及其他将在项目中工作的人有所帮助。那么实际上有一个单一的短名称的有效利用：循环计数器。

//这肯定是//注释的目的吗？

如果作业中有描述性的注释，那么您将两全其美：对变量和任何方程的描述都可以轻松地与教科书中的变量进行比较。

对于接口（例如方法签名，函数签名），我倾向于通过注释参数声明来解决。对于C / C ++，这会修饰.h文件以及实现的代码。

对于变量声明，我也做同样的事情，因为在上下文和命名中不知道变量的用法。（这适用于也没有强类型的语言。）

很多事情我们都不想阻塞变量名。角度（以弧度或度为单位），在精度或范围上是否存在一定的公差等。该信息可以提供有关必须正确处理的特征的有价值的主张。

我对此并不虔诚。我只是对清晰性感兴趣，并希望确保现在我下次忘记的自我访问代码时是什么。看着我的肩膀的每个人都有他们需要知道的内容，以了解哪些地方出了问题，什么是必不可少的（正确维护的最后一个关键）。

变量名过短是否有借口吗？

第一：在计算公式如E为命名能量E的可变= MC2是NOT过短的命名。用符号作为参数的短名称是无效

这个问题对我来说很有趣，我只能想到一个借口，那就是金钱。

例如说你对哪知道该文件是要下载一个客户端的JavaScript接线许多次。如果文件（以字节数为单位）越小越好，它会更便宜并且使用户的体验更好。

（仅是为了保持示例的“真实性”，不允许您使用压缩工具，为什么？安全问题，不允许使用任何外部工具接触代码库。）

我注意到其他答案没有提到匈牙利符号的使用。这与长度辩论正交，但通常与命名方案有关。

double dR, dCV, dK, dDin, dDout, dRin, dRout

所有这些变量开头的“ d”表示它们是双精度的。但是该语言仍在强制执行此操作。尽管这些名称很简洁，但它们最多可以冗余 50％！

如果我们要使用命名约定来减少错误，那么最好对未由语言检查的信息进行编码。例如，dK + dR即使在长度上添加无量纲数字也没有意义，但在以上代码中没有语言会抱怨。

防止此类错误的一种好方法是使用更强的类型。但是，如果我们要使用双精度，则更合适的命名方案可能是：

// Dimensions:
// l  = length
// rl = reciprocal length
double lR, rlCV, K, lDin, lDout, lRin, lRout

该语言仍然允许我们编写K + lR，但是现在这些名称提示我们这可能是错误的。

这是系统匈牙利语（通常较差）和Apps匈牙利语（可能较差）之间的区别

http://en.wikipedia.org/wiki/匈牙利语

在现代软件工程中，唯一的可接受的简短变量名的情况是它们存在于脚本中并且该脚本的吞吐量（通常通过网络）很重要。即使这样，在源代码管理中保留长名称的脚本，并在生产中最小化该脚本。