多词变量（以及一般标识符）中的单词顺序 [已关闭]

是否有任何关于由许多组件组成的变量/标识符的分支顺序的最佳实践或指南？

这很棘手，因为编程语言中的命名约定是传统、可读性和易用性的混合体：它们的设计重点是程序员的清晰度和理解力，而不是严格的语言一致性。
不同语言之间，甚至同一语言的不同项目之间都可能存在很大的差异（！

大多数命名约定的一般原则，特别是在 Java 和 C++ 等语言中，是使代码尽可能可读和可理解。

这就是为什么类似英语的命名（尽管不一致）经常受到青睐的原因：它使代码对广大开发人员来说更加直观，其中大多数人至少对英语有基本的了解。

当涉及到多词标识符时，许多编码约定鼓励程序员使用类似于自然语言的结构，因为它通常更具可读性和直观性。这通常涉及一个名词（表示变量或方法处理的事物），后跟提供额外上下文或指定操作的形容词或动词。

例如，Google Java 风格指南建议变量名称应为简短的描述性名词或名词短语。使用此约定，可以命名变量或 .
英语或其他口语的自然结构对大多数程序员来说往往更舒适，因为它很熟悉。它反映了我们自然的沟通方式。 对于说英语的程序员来说，它比 更直观，即使后者在语言学意义上可能更一致。employeeNumbertotalWidthcustomerAccountNumbernumberAccountCustomer

在您的示例中，变量名称的自然英语版本通常更易于理解，因为它们遵循更熟悉的语言模式。名称的一致右分支版本虽然在逻辑上一致，但有点难以解析，因为它们与英语的自然词序不匹配。

至于 OF Language 的 PRIME-MODIFIER-CLASS 单词方案，这确实代表了一种更一致的右分支命名方法，更通用的类别 （CLASS） 排在第一位，其次是 MODIFIER，然后是 PRIME。但即使在这种情况下，该约定的设计也着眼于使代码更易于阅读和理解，而不是实现严格的语言一致性。

但是，您关于深度嵌套数据结构中出现的不一致的观点得到了很好的采纳。对于复杂且深度嵌套的结构，语言上更一致的命名约定确实可能有助于理解元素之间的关系。这在需要由来自不同语言背景的人理解代码的上下文中，或者在处理特别复杂的数据结构时特别有用。

一般来说，最重要的因素是清晰度。如果特定的命名约定始终能帮助你和你的团队更有效地理解你的代码，那么这是一个有利于它的有力论据。
但是，如果你在一个更大的开发社区中工作，你可能需要平衡你对一致命名方案的个人偏好与该社区的普遍惯例。

您需要考虑命名约定的另一个方面：上下文的使用。

将计算结果分配给变量时，名称的选择取决于变量在周围代码上下文中的用途。如果该变量用于在循环遍历客户列表的循环中存储当前帐号，则（或为简洁起见）是一个直观的名称，因为它简洁地解释了变量的用途。currentAccountNumbercurrAccNum

通常，有一个比简单地附加字母或数字来区分相似变量更有意义的名称。例如，如果要比较的两个帐号属于交易的发送方和接收方，则可以将它们命名为 和 ，它们提供了比 和 更多的上下文。senderAccountNumberreceiverAccountNumberaccountNumberAaccountNumberB

您的示例（或或）突出了提出一致且直观且可读的命名方案的挑战。虽然与右分支方法更一致，但对许多开发人员来说可能更直观，因为它遵循英语名义结构。acctNoCustomerA/acctNoCustomerBcustomerAAcctNo/customerBAcctNonoAcctACustomer/noAcctBCustomeracctNoCustomerAcustomerAAcctNo

通常，最佳做法是选择清晰、简洁和描述性的变量名称。一致性很重要，但不能以牺牲可读性或理解力为代价。

因此，虽然一致的左分支或右分支命名方案在语言上可能更正确，但它不一定是代码可读性的最佳选择，特别是对于习惯于类似英语的命名约定的开发人员。

另请参阅 Miltiadis Allamanis、Earl T. Barr、Christian Bird 和 Charles Sutton 的“学习自然编码约定”。

它引用了 Samir Gupta、Sana Malik、Lori Pollock 和 K. Vijay-Shanker 的“Part-of-speech tagging of program identifiers for improved text-based software engineering tools”（此处为 pdf）。

为了帮助程序理解，程序员主要通过遵循软件中的命名约定来选择方法、类、字段和其他程序元素的标识符。
这些软件“命名约定”遵循系统模式，可以传达软件工程工具可以利用的深层自然语言线索。例如，它们可用于提高软件搜索工具的准确性，提高程序导航工具推荐相关方法的能力，以及提高其他程序分析的准确性。

将多单词名称拆分为组成单词后，提取准确的自然语言信息的下一步是使用词性 （POS） 标记每个单词，然后将名称分块为自然语言短语。

最先进的方法，其中大多数依赖于在自然语言文档上训练的“传统 POS 标记器”，没有捕获程序元素的句法结构。在本文中，我们提出了一个用于源代码名称的 POS 标记器和语法分块器，它考虑了程序员的命名约定，以理解程序元素的常规、系统命名方式。

这些文章可以帮助你的研究。

关于OP的评论：

似乎编程社区没有仔细考虑过我的具体问题

1. 你是对的：绝大多数主流编程约定并没有直接解决变量或标识符命名中的左分支与右分支语言结构。
   大多数约定都强调清晰度、一致性和在特定语言或生态系统中使用已建立的模式，并且它们通常推荐或规定受英语语法和可读性影响的模式，而不是严格的语言考虑。

假设逻辑结构为 ，一个真正完全右分支的名称可能是 ，反映了 “” 和 “” 紧密结合在一起的层次结构，但 “” 不直接连接到 “” 或 “”。[accounts[customers[a]].number]Acct_CustomerA_NoCustomerAAAcctNo

2. 您的第二个观察引入了一个有趣的观点。使用下划线或其他分隔符来反映不同级别的层次结构确实有助于以变量的名称表示数据的结构。
   在某些上下文中，类似的东西可能更直观、更易读，尤其是在处理复杂的数据结构时。它是一种直观地将相关元素组合在一起的方法，类似于在数学表达式中使用括号来显示运算顺序的方式。
   这种命名方案可能需要一些时间来适应，但在某些情况下它可能是一种有用的方法。Acct_CustomerA_No