关于命名变量的思考

我不记得什么时候听到的，但它卡住了。当打趣的＆＃34;点击＆＃34;对我来说，我无法休息直到找到一个被驳斥的框架。但这已经有6年了，除了是，是的，我仍然无法回答上述问题。

我可以肯定的是，缓存失效是这两者中比较难的一件事，因为某些底层的OCD，我们大多数人都会选择两个任意的常数来决定扫描频率和TTL。我什至推测，编程的大部分演变都是围绕不尝试选择这两个任意数字的怪异的精神实践。整体上，函数式编程甚至可以理解为与此相关的一系列禁忌，因为共享的OCD如果没有引发宗教的好处。

我离题，我既不老，也不明智，也不疯狂谈论缓存无效，所以我将谈论编程中第二难的事情，命名。

也许我在这里含糊不清，但请忍受我，我正在尝试介绍导致创造文明并使我们与猿类区分开的做法

从理论上讲，名称可以是任意的，在ASM级别上，用地址替换名称是合理的。然而，名称是如此有用，以至于即使在编译代码时它们也可以保留下来，这大概是因为当人们被迫查看生成的ASM时，它们有助于保持理智。

就名称有助于使代码有意义而言，它们在不同的级别上运行。

名称有助于将开发人员与软件的最终目标联系起来。我认为OO成为教学范式受欢迎的主要原因是一种示例程序的文化，这种程序使用了引用“真实世界”的名称。使用＆＃34; Shop＆＃34;之类的字词和＆＃34; Transaction＆＃34;和＆＃34;购买＆＃34;和“转移到”，这使学生的无聊大脑有了一些可以依靠的现实。

名称有助于构建软件的思维导图。在这方面，名称的功能与我们向世界注入的任何其他任意类别的功能非常相似，无论是我们用来指动物，其他人，夜晚的天空，还是使代码的相似性更加明显，排便的内容。从这个意义上说，名称应优化代码映射，这对于编写该代码的人是有意义的。

不过，我只是在开玩笑，这真的是一个团队＆＃34;和一个团队这是一个真正的团队，人们来来往往，记忆力不佳且思想变化的人们阅读地图。

我们已经可以在这里看到一些折衷。现在对您有所帮助的名称不一定会在5年后对团队有所帮助。也许让IHateThisFingLoop是一个愤怒的出口，或者提供一些必要的喜剧性救济，例如val steves_moms = FAT32（）。但是，暂时命名经常会适得其反。不仅在命名导尿时。现在，我们正在开发的代码有一个很好的映射，一个明显的＆＃34;在事后看来，名字可能是一个可怕的选择。根据我们的思想背景，trx名称可能是write_new_credentials_transaction的受欢迎的缩写，或者它可能是引起新闻的安全性错误的原因。

名称并不是仅仅用来表达我们已经拥有的概念，一旦选择了一个名称，如果经常遇到它，它就会变成它自己的概念。只需查看一下古老的科学，便可以看到现在植根于人们的心智数据库中的任意变量名称以一种不可简化的方式描述了现实的基本本质。 pi和e表示圆，x表示未知的概念，c表示如果麦克斯韦方程式成立时物体可以行进的最大速度等）。

如果存在一个完美命名的代码库，那么除了易于理解之外，它还可以为读者提供对其用途的惊人理解。令人遗憾的是，＆＃34;完美地命名了＆＃34;人与人之间甚至人与人之间（随着时间的流逝）都会有所不同。

我也认为＆＃34; Experience＆＃34;人们使用的名称可能会因他们使用的代码库而有很大差异。在具有大量现有名称和命名标准的大型代码库中工作，与从头开始构建代码提供了完全不同的命名体验。

确实，了解代码库甚至某种语言可能可以归结为熟悉其所有名称和命名约定。

可能有一种人可以记住stdlib中所有函数的名称，但对语言一无所知。但是，尽管我们的教育系统试图针对可能导致的精神疾病进行优化，但对于绝大多数了解语言的人来说，仍然可以归结为了解词汇。

命名事物的前戏是关于命名事物的约定。约定规定了在各种情况下可以给出的名称的界限。例如，我通常强加的约定是：

如果变量的类型在用法上不明显，请使用暗示该类型的名称（例如customer_arr，equation_dict）

我们的编码指南中都没有写下来，甚至只是初次贡献者，人们都对此有所了解，我对此感到着迷。

新人们似乎想念很多事情，我不得不一次又一次地重申，但命名从来都不是其中之一。加入一个新团队参加他们的会议对我来说也从来没有问题。

尽管如果公约太小众或太多，这种采用的便利性可能会消失吗？

如果您想了解命名，请挖掘约定，但是由于上述问题（人们本能地抓住它们），很难找到好的约定。一些约定非常好，它们被编入语言语法中。

您是否知道const（即不变性）在80年代初C ++出现之前在任何流行的编程语言中都是没有意义的？人们（大概）曾经将它写为变量名的一部分，并希望它能被惯例所尊重。

对象和类的概念本质上是命名约定和文件放置约定的混合，至少在必要的情况下，它们混合在一起。

甚至更令人怀疑的是，＆＃34;键入＆＃34;最初只是一个命名约定，尽管小行星摧毁了可以用来确定结论的大多数证据。但是如今，类型似乎在缺乏类型系统的语言中用作名称的一部分。

但是，问到2050年的读者时，我听说在您的时代曾经是一个称为“数学”的领域，这是人类在计算机之前所做的事情，他们尝试（而且经常惨败）使用大脑进行执行形式逻辑。

您在重塑时非常有洞察力，并且我同意我们不能理解编程中的命名，而忽略了3000年的数学命名。编程中最基本的名称，大多数语言之间共享的名称，运算符的名称（+，-，*，/，^，＆amp; ...等）是从数学中提取出来的或从中得到启发的。

在我任意选择的世界观中，数学是一个不完善的工具，在现代人的大脑和现代机器出现之前的某个时间里，不完美的创造者就建立了数学，因此它充满了缺陷和局限性。事物命名方式中最明显的缺陷之一。

当使用＆＃34;数学符号＆＃34;时人们倾向于使用非常短的名称，即1个符号长。程序员可能会写类似于以下内容的内容：

但是，以数学符号表示，写任何比

减少诸如沙子或黏土之类的材料上的书写量，这些材料便宜且易于擦除，但难以书写。

这并不会引起很多问题，因为我们的大脑不太擅长执行形式逻辑。因此，给定的数学构造可能包括2个，3个，5个或10个实体。但是，即使对像欧拉这样的天才或像欧几里得这样的大策展人来说，假设一个具有数千个变量的方程式似乎也很疯狂。

当然，我们生活在一个年龄适中，才华横溢的8岁小孩子可以学习像Scratch这样的玩具语言并在编写Web应用程序时偶然构造这样的方程式的时代。如今，我们只需要编写方程式，从历史上看，我们的大脑也负责执行这些方程式。这将可能性的范围限制在一个如此微小的范围内，我颤抖着去思考那些可怜的灵魂的悲惨状况，它们帮助我们到达了可以建造计算机的地方。

仍然，前面提到的兴趣计算功能起作用的原因是作者可以简单地预先指定：＆＃34; p代表本金，r代表利率，q代表季度数＆＃34;。

直到80年代，这种做法一直在我们中间保持着一种怪异的方式，即变量名通常在文件初始化之前就在文件的开头声明。尽管对您来说似乎很疯狂，但是C和C ++允许您编译以下代码：

有人告诉我，这曾经是古代人初始化事物的首选方式，而且人们不得不认为它可能以一种扭曲的方式产生于数学将“定义”分离的方式。 ;来自＆＃34;用法＆＃34;对于它的变量。

也许我在这里有点笨拙，所以让我们将示例移至一个函数，该函数可计算复利：

在这里，我们看到了一个有趣的怪癖，它极大地影响了我们如何命名事物，将值重新分配给变量。

我必须承认我不确定为什么没有这样做。这似乎是一种潜在的好习惯，但是我很惊讶它如此好，以至于3000年前人们偶然发现了它它卡住了。

无论哪种方式，这似乎对我们命名事物的方式都产生了显着影响，考虑上述功能，但写为：

函数calc_quarterly_compounded_savings（本金，利率，季度）：让0中的i的收益= 0..quarters：收益+ =（本金+收益）*收益率本金+收益

另一个人可能会争辩说，通过在上述内容上增加收益，我们从抽象的功能转向了对现代货币体系背后的基本概念之一的直观解释。

所有这些都是因为我们牺牲了一些简单性（添加了一个变量）但获得了一个概念（收益）。我们还可以假设一些中间立场，例如：

函数calc_quarterly_compounded_savings（本金，利率，季度）：让累加= 0中i的本金。季度：累加=累加*累加的收益率

上面在“原理”和“原理”之间保持了区别。和＆＃34;获得＆＃34;在第二种实现中展示，同时保留了第一种实现的优雅逻辑。

但这是毫无意义的有趣的是，赋值让“累加=主体”似乎与我之前所说的数学符号，定义和用法的分离密切相关，但有一点曲折。

顺便说一句，数学当然可以通过引入另一层抽象（幂）并说出：

尽管在实践中，这种方法似乎经常遇到限制（请参阅20世纪初）。

我再说一遍，我们能否将数学和编程之间的区别归因于部分原因在于编程是随着“免费”而长大的？还是数学的婴儿期是纸很贵的时代？我认为并不完全，但这是我们不容忽视的一个因素。

我发现有趣的是，既然Rust和Scala已经成为一件事，功能语言（主要）已经从安全地激励他们的选择过渡到纯粹在美学基础上激励它们。

我不想深入研究整个数学/函数美学，但就命名而言，我认为它们是完全不同的。数学最终禁忌使用超过一个符号的名称，因此发现自己有数百个怪异的符号，根据使用的领域，每个符号可能具有数十个甚至数百个不同的定义。

如果我要通过使用Haskell，Clojure和Elixir编写的标准库和软件来判断函数式编程，我可以轻松地断言它们的名称通常具有很强的表达力和较长的名称。

令人惊讶的是，短名称在命令性代码中经常找不到，只是随机查找几个C ++或C代码库，您一定会看到大量1-3个字符的实体，这使您感到困惑。

可能有原因吗？可能不是，但是让我推测一下：

简短的姓名要求我们拥有＆＃34; mental map＆＃34;在＆＃34;工作缓存＆＃34;中的每个变量或排序，您必须能够在一个上下文中立即将p映射到主体，在另一个上下文中进行预测，并在另一个上下文中进行分区。

因此，从这个意义上说，短名称可能是限制给定逻辑块大小的一种保障措施，毕竟，此临时思维导图只能容纳几个符号并且仍然有效。

另一方面，尤其是在流程中，我们可能会倾向于使用表达性名称来编写大小庞大的逻辑块。函数式编程似乎还有其他方法可以防止这种风格出现，因此可能导致短名称更成为命令式语言的主要内容？

关于短名称的另一件有趣的事情是，由于需要与它们一起使用的上述思维导图，它们可能成为在思维的思维方式之间进行切换的一种有趣方式。

就个人而言，当某些逻辑变得过于复杂时，我要经过的步骤是：

我认为，短符号更适合于考虑算法问题的解决方案，这一观点可能有一定的优势。

也可能是因为它们经常被更多的＆＃34; raditional＆＃34;使用。和＆＃34;与数学相关的＆＃34;由于习惯或数学嫉妒而导致CS领域（以及物理领域）出现的情况。

答案可能还在于习惯和内在素质的边界，大多数人可能被教导要在年轻时将言语交流和逻辑分开（出于明显的原因），并且某些队列（例如，看到1个字母的变量）可能会使人倾向于思考在逻辑/数学上，而其他人（例如，看到可区分的单词）可能会引起平淡无奇的情绪。

但是，考虑一下，无论出于何种原因，速记名称都允许使用更聪明的代码。我们应该使用它们吗？

我不这么认为。以后必须阅读这些内容的人都会面临额外的困难，即必须处于一种特殊的“心态”中。使代码有意义，这是一种可能难以实现或烦人的心态。

更不用说您自己可能被迫阅读该代码，而未来的您可能会变得笨拙，更加疲倦，或者只是缺乏时间或兴奋。

实际上，很奇怪地看到名称如何根据在代码库上工作的团队的类型而有所不同。这可能是一个笼统的概括，但是我倾向于在更多的＆enterprisey＆＃34;中看到更长，更详细的名称。环境，而在更多＆＃34; hobbyistic＆＃34;中较短的环境或＆＃34; startupy＆＃34;环境。

有人写道：purchase_customer_transaction_instantiation.CollectAllInventoryFromCustomerShoppingCart与buy_trx.get_cart_content是一个相当可靠的指标，可以确定它们是在小型公司中还是在公开上市的庞然大物中工作。

较大的团队和较大的公司通常在更严格的约束下运作。代码库往往更复杂和更老，有很多人在使用它们，而他们很可能经过许多双手才能达到这一点。员工通常在背景和技能方面涵盖范围更加广泛。由于公司内部的依赖性以及需要为更大的团队更新代码库思维模型的需要，无论复杂程度如何，重构都变得更加困难。

长名可以帮助所有这些事情。正如我之前所暗示的，＆＃34;知道＆＃34;代码库类似于知道所有名称。更冗长的名称似乎是确保每个人都在同一页面上的一种非常明显的方式。关于正在做什么。

我不能指着一个，但是用错误的方式使我感到困惑。从表面上看，它让人感到光顾。事物的名称是os＆＃34; obvious＆＃34;从而部分抵消了“获取”的乐趣我所处的环境或提出具有表现力（即小尺寸，高信息量）名称的挑战。

如果您在工作内存中缓存了上下文相关的映射，则较短的名称可以提高操作效率。

即使这样，短名称也有要求熟悉潜在的＆contexts＆＃34;的缺点。代码库内部以及它们如何交互以构建此地图。

从感觉和美学的角度来看，我希望答案是否定的。从简化派的角度来看，我可以看到很多关于长名称的简单明了的论据，而只是一堆模糊的原因，他们更喜欢短名称。

我在这里探讨了一些有关名称的事情，但总的来说，与我开始撰写本文时相比，我更加困惑。我唯一可以肯定地说的是：

每个代码库都有命名约定，并且它们通常是隐式的，人们在选择它们时几乎没有问题。

上下文对于确定好名字非常重要，这对于您的团队具有“进行上下文切换”的能力非常重要。可能导致命名模式大不相同。

从表面上看，较长的名称似乎比较好。但是（某些东西）短名称可能有助于解决问题和代码分区。

最佳的命名惯例已经将其变成一种语言，如果您经常使用命名惯例，那么它可能是您喜欢的语言的一个很好的指南。

我认为在这篇文章的后续文章中，我有四个主题有兴趣进一步探讨。

一种是类似IDE的工具和名称之间的链接。例如，命名时可以使用表情符号和颜色吗？我在想，例如，具有简短而富有表现力的名字，不会触发“语言推理模式”。通过表情符号。或通过颜色划分上下文或某些属性（部分IDE已经通过突出显示来做到这一点）。有人在尝试这个吗？如果是这样，请告诉我。

其次，我很想对流行的开源代码库进行名称分析，并尝试收集一些汇总统计数据以及寻找模式...甚至可能找到一种有趣的方法来使用一些拥抱的面孔模型来从他们那里提取一些见识。

第三，我想对具有较长git历史的各种代码库进行时间变化分析，以了解名称如何随着代码库和维护者数量的增长而发展。

第四，我很奇怪地尝试了一个实验，该实验提供了一个数学工具。和一个＆＃34;代码＆＃34;一群人习惯使用相同功能的版本，并且习惯于同时使用两种表示形式并询问一些基本问题（如何使它更高效/更短，如何对其进行修改以执行x ...等） 。但是我担心在这里选择人口是困难且昂贵的（进入CS或ML的硕士/博士学位课程的数学本科生可能会工作...）。

对于在房间中给某些大象命名而没有提供适当的封闭性，我深感抱歉，但是对于像命名这样的全球性话题，我恐怕这样做几乎是不可能的。