对于我目前正在使用的代码库，这已经变得非常沮丧。我们的许多变量名都是简短且无描述性的。我是该项目上唯一的开发人员，并且没有关于大多数功能的文档，因此我不得不花更多的时间来追踪它们的含义。正在阅读一些更新光学表面定义的代码。开始时设置的变量如下：难。我所知道的是，这是一个从特定表中某个位置的特定行中解析出的变量。经过一番搜索，我发现了它们的含义：它延长了一些行，但是我觉得这是一个公平的权衡。但是，在很多代码中都使用了这种命名方案。我不确定这是来自开发人员的作品，他们是通过使用较旧的系统而学习的，还是背后有更深层的原因。以这种方式命名变量是否有充分的理由，或者在遇到变量时将其更新为更具描述性的名称是否合理？

评论

在我看来，在这种特定情况下，这些是直接从长期数学公式中复制的变量名称。
我唯一可以接受的借口是“我的同伴在检查代码后告诉没关系”
如果您发现由于变量名短而无法理解数学代码，请注意，这可能是因为您不了解数学，而不是因为名称太短。更改您不了解的数学表达式并不是一个高可靠性的过程。一旦理解了数学，变量名的长度就无关紧要了。如果需要学习，请别人帮个忙，并在数学的一些相关描述中引用（在评论中）！
认可以大金刚命名的任何标识符：dK =圆锥常数。
相反，人们可能会问，对领域字段的无知是否足以证明它无视其惯例。最后，它取决于上下文。

#1 楼

这些变量名称似乎是基于您期望在物理教科书中找到的有关各种光学问题的缩写。这是短变量名通常优于长变量名的情况之一。如果您有习惯使用Rin，Rout等常用缩写的物理学家（或习惯于手工求解方程式的人），则使用这些缩写的代码将比使用较长的变量名的代码更清晰。它还使将论文和教科书中的公式与代码进行比较变得容易得多，以确保代码实际上正确地进行了计算。内半径（在物理学论文中，in将显示为下标），Rout表示为外半径，等等。尽管他们几乎可以肯定地将诸如innerRadius之类的东西翻译成更熟悉的命名法，但这样做可以使代码对那个人不太清楚。这将使得发现熟悉的公式被错误编码的情况变得更加困难，并且使得将代码中的方程式与在纸张或教科书中找到的方程式进行相互转换也变得更加困难。

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

评论

并且如果工作人员中没有物理学家或数学家？代码基本上留给我了。基本上没有记录。阅读描述性名称会更困难吗？

– KChaloux
2012年11月20日20:40
+1期望程序员理解他所从事的领域并非没有道理。另一方面，在数学工作中，变量通常在方便的地方定义。在这样的代码中，我期望显示长格式的突出注释。

–卡尔·比勒费尔特（Karl Bielefeldt）
2012年11月20日20:52
+1：您基本上要说的是，了解他们正在工作的域的程序员将理解变量名。即使变量名较长，在许多项目中也是如此。例如。在军事战略游戏中，名为column的变量很可能意味着与图表软件不同的含义。

–史蒂文·埃弗斯（Steven Evers）
2012年11月20日20:57
在医学程序设计中，您经常会发现在编程领域中存在的术语。例如，对于眼科，您将看到OU，OD和OS。这些表示哪只眼睛，例如ouSphere可以引用右眼眼镜处方中的“球体”组件。如果您了解要为其编程的业务领域，那么您将成为一名更好的程序员。

– Bill
2012年11月20日23:57
+1表示与论文和文本中的方程式和公式匹配的短名称。在执行此操作时，我将包含有关在哪里可以找到原始参考资料的评论。

–杰伊·埃尔斯顿（Jay Elston）
2012年11月21日在1:08

#2 楼

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

一般来说，可以说变量作用域越短，名称应越短。循环计数器通常只是单个字母，例如i，j和k。局部变量类似于base或from和to。这样，全局变量就更加详细了，例如EntityTablePointer。也许您使用的代码库未遵循这样的规则。这是进行一些重构的一个很好的理由！

评论

数组索引的i，j和k至少可以追溯到Fortran。任何自重的程序员都将熟悉此约定。

– Dominic Cronin
2012年11月20日在21:24
我通常不写i，j，k，而是写诸如personPos之类的东西，因为那样我就不会忘记要迭代的内容以及索引所代表的含义。

–马尔科姆
2012年11月21日下午4:56
-1，我确实使用长名称进行数组索引迭代，但是我给它们起了有意义的名称，而不是显而易见且毫无意义的arrayCounter。使代码更易于阅读，并且至少在复制/粘贴此内部循环时使您避免踩踏外部计数器。

–奥列格·沃尔科夫（Oleg V. Volkov）
2012年11月21日，11：10
counter是名词或形容词。 Count是名词或动词。当然，我仍然不会称呼arrayCounter，而是使用personIndex或row或任何描述我正在查看的内容。

–Wayne Werner
2012年11月21日13:45
当我执行单循环时，我使用i。但是，一旦我过渡到嵌套循环，就会删除i命名法。这样做的原因是因为我真的想跟踪正在使用哪个循环变量，而在密集代码中，i vs j可以说是相当欺骗。对我来说，使它更具可读性并添加更多的空格是固有的必要。

– jcolebrand
2012年11月21日在18:07

#3 楼

代码的问题不是短名称，而是缺少注释，不能解释缩写，或者指向一些有关衍生变量的公式的有用材料。

代码只需假设问题域熟悉即可。

很好，因为问题域熟悉可能是理解和维护代码所必需的，尤其是在“拥有”它的人的角色下，因此它理所应当您将获得熟悉的知识，而不是去加长名称。

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

评论

最终最终得到了这样的东西。

– KChaloux
2012年11月21日13:42
错了没有理由使您的代码难以阅读，以迫使人们花更多的时间“学习”它。您不是在教书，只是在让别人慢下来。而且，几乎永远不会只有一个代码所有者。您是近视和自私的人。

–xaxxon
13年2月3日，下午3:57
错误的是你的解释，而不是答案。该代码实现了一些存在于该代码之外且独立于该代码的数学运算。保持相同的命名是有帮助的。维护代码的人可能必须在数学之外学习，而不必在两个命名方案之间映射会帮助该人。

–卡兹
13年2月3日在4:09


#4 楼

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

评论

我认为cv，din和dout并不是立即显而易见的（尽管它们显然是在特定领域建立的）。我不会讨论x和y，因为笛卡尔坐标适用于任何数量的字段，并且对中学和高中的每个人都有教益。

– KChaloux
2012年11月21日在1:01
并且x和y虽然很常见，但并不包含隐含的重要方面，例如原点在哪里。

–罗斯·帕特森（Ross Patterson）
2012年11月21日下午2:28
@RossPatterson：但是，在许多情况下，这根本不重要。例如，考虑一个循环，例如list_of_coordinates中的（x，y）：print x，y：尝试理解代码时，原点并不特别重要。

–布莱恩·奥克利（Bryan Oakley）
2012年11月21日15:00

#5 楼

根据“清洁代码”：

变量名称应：


要有意揭示
避免虚假信息
进行有意义的区分>可发音
可搜索

for循环中普遍使用的i,j,k,m,n是例外。这些名称是错误的名称。

此外，由于每个方法都必须简短，请使用前缀表示不再使用作用域或类型。 

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;


评论

这些变量可能在代码中的数学公式中使用。使用简短的变量名更容易阅读数学公式。我在大多数代码中都使用长变量名，但是数学上最好使用短变量名。随机示例：考虑使用长变量名将持续多长时间。

– MarkJ
2012年11月21日16:19
@MarkJ你是对的。

–图兰斯·科尔多瓦（TulainsCórdova）
2012年11月21日在20:58
中间结果具有减少和隔离编程错误的额外好处。我们的大脑一次只能处理这么多的信息，很难在类似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 ...;

–失明
13年2月2日在17:55
如果那是您的面包和黄油，那并不难。

–拉杜
13年2月2日在18:30
重点不是写单线。但是问题是，如果您现在需要更改某些内容并使用另一个公式，则会遇到一个问题，即花很长时间才能确定教科书中R所引用的long_name。使用中间结果，但要使复杂的数学尽可能靠近问题域，以便在需要添加功能时可以实际维护它。

– slebetman
2014-09-17 6:25


#6 楼

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

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

（2），您将比较当前版本与过去的版本，以查看发生了什么变化，这是不可能的。这将使以后的代码维护更加困难。

评论

绝对正确，但是缺乏理解的风险更大。

–罗斯·帕特森（Ross Patterson）
2012年11月21日在2:27
如果您的工具无法处理您提到的简单问题，那么您将遇到更大的问题。

–AndSoYouCode
2012年11月22日下午16:17
答案（1）合理的自动测试范围和合理的封装，（2）熟练掌握版本控制。

–金刚
18 Mar 9 '18 at 11:34

#7 楼


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


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

数学表达式越小，通常一次查看整个内容就越容易。尽管是这样，但它们可能比dIn和dOut更好，因此没有重复的D可能导致容易打错。与，然后淘汰自己并重命名为更长的形式。特别是如果您负责该代码。

评论

至少我肯定摆脱了系统匈牙利符号...

– KChaloux
2012年11月20日在21:03
领先的d是匈牙利人？我认为这是微积分，如dx ^ 2 / dx = 2x。

– Shannon遣散费
2012年11月20日23:20
如果我自己看到dDinnerAperture，我将其读为“ Dinner Aperture”，并且想知道这是否只是说“你的嘴”的有趣方式。从来都不喜欢“大写字母后跟小写字母”样式。有时会造成混乱。

–达雷尔·霍夫曼（Darrel Hoffman）
2012年11月21日，3：35
+1这就是答案。长数学公式使用短变量名更容易阅读。这些变量可能在代码中的数学公式中使用。使用简短的变量名更容易阅读数学公式。我在大多数代码中都使用长变量名，但是数学上最好使用短变量名。随机示例：考虑使用长变量名将持续多长时间。

– MarkJ
2012年11月21日在16:20
@ShannonSeverance我同意你的看法。来自工程学背景，在数学意义上使用变量名称时，d应该绝对用于微积分（如此处经常提到的）。

– CodeMonkey
17年1月1日在9:28

#8 楼

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

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

最近，为了使用一个真实的例子，我正在创建一个Javascript类，该类需要进行纬度调整，并告诉您在给定日期所期望的日照量。

为了创建这个日d类，我提到了大概六个资源，《天文学年鉴》和其他语言（PHP，Java，C等）的代码片段。

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

但是，如果您具有物理知识，则可以理解它们的本质。我不希望其他人接触到此代码，所以为什么要使用冗长的变量名呢？有时，当变量名是暂时的时，也就是说，它们仅用于临时分配一些值，那么使用冗长的版本通常是没有意义的，尤其是当变量的上下文说明其用途时。

#9 楼

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

在我的情况下，我正在高级机器人课程中进行航点导航，我们在KISS-C中对机器人进行编程。我们需要用于当前和目标（x，y）坐标，（x，y）距离，当前和目标航向以及转角的变量。

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

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

#10 楼


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


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

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

所有常规编码指南都告诉不要以表示类型的第一个字母来命名变量（如您的情况），因为这样很容易浏览所有现代IDE中的代码。

评论

是的，不管人们最终说什么，该要素都会消失。发现我正在更新的代码库中存在一种半匈牙利半非精神分裂症。

– KChaloux
2012年11月21日20:20

#11 楼

我可以想到一个原因，即变量名应尽量短。

短名称容易用较短的跨度读取，因此注意范围也较短。

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

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

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

评论

我们不会将单词作为一组字符来阅读，而是将它们作为形状阅读，并在快速理解失败时有条件地解析细节。一个单词要花更长的时间才能阅读的长度远大于4个字符，并且我们能够在头脑中处理camelCase和其他方法来分解可变名称单词作为单词边界。我怀疑阅读测试是否会证明短名称会提高阅读理解速度。取而代之的是，删除可识别的单词会降低速度，直到吸收新单词（您自己指出）。

–失明
13年2月2日在18:07

#12 楼

以@zxcdw略微不同的方式来构造框架，并在方法上进行详细说明：

函数应该是纯净，简短和某些功能的完美封装：黑盒逻辑，无论它已经使用了40年，一直保持不变，它将继续执行其设计的工作，因为它的界面（输入和输出）是健全的，即使您对它的内部一无所知。

这是您要编写的代码类型：这是持久的代码，易于移植。函数调用，以保持代码的细粒度。

现在，有了适当描述性的函数名称（如有必要，请加上详细说明！），由于范围如此，我们将对误解的缩写名称的可能性降到最低小。

#13 楼

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

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

评论

注意int dummy_variable_for_for_loops;尽可能具有描述性。

–卡兹
2012年11月20日23:50
-1，因为此答案令人困惑。首先，它说没有充分的理由，然后最后说实际上是有的。如果改写不矛盾，答案会更好。

–布莱恩·奥克利（Bryan Oakley）
2012年11月21日0:50
我将其更改为“根据需要进行描述”。如果简称传达了变量的目的，那么可以使用简称。

– Maximus Minimus
2012年11月22日上午9:02

#14 楼

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

#15 楼

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

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

有很多事情我们不想阻塞变量名。角度是弧度还是度，是否在精度或范围等方面有一定的容忍度。这些信息可以为必须正确处理的特性提供有价值的主张。我只是对清晰性感兴趣，并希望确保我现在下次忘记的自我访问代码时是什么。看着我肩膀的任何人都需要知道什么，才能知道哪里出了什么问题，什么是必不可少的（正确维护的最后一个关键）。

#16 楼


变量名称过短是否有借口？用符号作为短名称的参数无效

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

例如，您正在为客户端接线的javascript，该客户端知道文件每秒将被下载多次。
如果文件（以字节数为单位）为

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

评论

您的示例仍然不是很现实。

–拉杜
13年2月2日在18:33

#17 楼

我注意到其他答案没有提到匈牙利符号的使用。这与长度辩论正交，但与总体上的命名方案有关。翻倍；但是无论如何，这种语言正在强制执行。尽管这些名称很简洁，但它们最多可以冗余50％！被语言检查。例如，即使在长度上添加无量纲数字也没有意义，但没有一种语言会抱怨上面的代码中的dK + dR。但是，如果我们要使用双精度，则可能更合适的命名方案是：给我们一个暗示，这可能是错误的。 wikipedia.org/wiki/匈牙利语

评论

实际上，如果正确声明单位，C ++可能会抱怨K + lR。使用SI单位，它可以进行尺寸检查和单位转换。添加3_feet + 2_meter应该没问题，而2_meter + 1_second应该是编译时错误。

–MSalters
2014年9月17日上午11:46
@MSalters太酷了；我还没有想到一个模板/宏方法。尽管如此，在这样的“与语言无关”的问题中，无论语言是否被称为“类型”，我都会将所有编译时单元检查归入“更强的类型”框架下；

–Warbo
2014年9月17日下午16:01
模板，必不可少。您不能在宏中进行必要的类型演算。

–MSalters
2014-09-18 15:20

#18 楼

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

评论

在执行将这些术语视为该领域的常识的数学运算时会怎么样？示例：在e = mc ^ 2中使用M代替“质量”

–安迪·亨特（Andy Hunt）
2012年11月20日20:38
@andyBursh-在那儿我会小心的。程序员在他们的问题领域通常不是专家（甚至不是专家）。就是说，这样的事情可以没事，特别是如果有适当的注释链接到所讨论的公式；那么我已经忘记了这种情况。

– Telastyn
2012年11月20日20:44


@Telastyn-但是，如果您假设程序员不是专家，那么通常会导致使用含义非常明确的缩写并将其转换为至少有点含糊的较长名称（即有人决定命名局部变量半径，当它存储的内半径不了解时比Rin更加模糊。然后，每当涉及方程式的讨论时，非专业开发人员就必须在其独特的术语和企业理解的术语之间进行转换。

–贾斯汀·凯夫（Justin Cave）
2012年11月20日在21:07
循环计数器的“ i”怎么办？或在处理坐标时使用“ x”和“ y”？还是范围只有两行代码的变量？

–布莱恩·奥克利（Bryan Oakley）
2012年11月21日，0：51
不赞成这个答案。从事包含复杂数学表达式的程序的程序员最好至少能够阅读规范中的公式，否则它们将不起作用。这不是问题领域的知识，而是必不可少的技能-在从事数学程序之前需要具备一些基本的数学能力。如果程序员无法访问规范公式，那将是另一个问题-不能仅通过注释来解决。

– MarkJ
2012年11月21日在16:22