Lov*_*ure 5 language-agnostic naming-conventions
这是一个关于变量命名（或一般标识符的命名）的问题。
\n中心语（右分支）语言往往有后名词修饰语，而中心语（左分支）语言往往有前名词修饰语。修饰语包括形容词、副词、所有格代词和指示词。这是一个例子（英文翻译：“大声的音乐”）：
\n一旦我们把例子拉长，我们就会发现，实际上，语言在这方面是非常不一致的，英语就是一个很好的例子。另外，根据我个人的经验，单词越短，它出现在左侧的可能性就越大（出于心理语言学解析的原因：您可以通过这种方式更早地辨别树结构）。但是，在命名由许多单词组成的长变量时，在这方面保持一致不是有好处吗？
\n这里有些例子：
\nredblackTree_leftSubtree_color（混合；自然英语）vs treeRedblack_subtreeLeft_color（一致右分支）\xe2\x80\x93 注意我如何没有将“subtree”更改为“treesub”（将其视为不可更改的词汇化块）old_bTree_order（混合；自然英语）与bTree_old_order（一致右分支）\xe2\x80\x93 在这种情况下，我没有将“bTree”更改为“treeB”myStrings_set_size（混合；自然英语）与stringsMy_set_size（一致右分支）len_median_sortedListCopy（混合；自然英语）与listSortedCopy_median_length（一致右分支）arrayIndexOutofboundsException[ ArrayIndexOutOfBoundsExceptionJava 中]（混合；自然英语）vs exceptionArrayIndexOutofbounds（一致右分支）我个人非常喜欢非常严格的右分支命名。这样，我们总是从高级/抽象/一般概念到低级/具体/专业概念，即从大整体到小组成部分。不用说，这违背了英语中的自然语言用法。
\n顺便请注意，严格左分支命名的情况是，通常可以从最具体的元素猜测类型。例如，order_old_bTree几乎可以肯定是一个整数。此外，最左边的元素与当前的缩进级别很好地对齐。
关于由许多组件组成的变量/标识符的分支顺序是否有任何最佳实践或指南？
\n我浏览了非英语国家的人用英语编码的 108 个答案吗？，但我找不到任何一个解决这个方面的问题。
\n我在相应的维基百科文章中可以找到的唯一相关内容是OF 语言的 PRIME-MODIFIER-CLASS 单词方案（除了维基百科所说的之外，我对此一无所知）。
\n此站点上至少存在 2 个相关但编程语言\xe2\x80\x93 特定的问题：
\n\n\n关于由许多组件组成的变量/标识符的分支顺序是否有任何最佳实践或指南？
\n
这很棘手，因为编程语言中的命名约定是传统、可读性和易用性的混合体：它们的设计重点是程序员的清晰度和理解性，而不是严格的语言一致性。
\n不同语言之间甚至同一语言的不同项目之间可能存在很大差异（！）。
大多数命名约定的一般原则，特别是Java和C++等语言中的命名约定，是使代码尽可能具有可读性和可理解性。
\n这就是为什么类似英语的命名（尽管它不一致）经常受到青睐：它使代码对于广大开发人员来说更加直观，其中大多数人至少对英语有基本的了解。
\n当涉及多词标识符时，许多编码约定鼓励程序员使用类似于自然语言的结构，因为它通常更具可读性和直观性。这通常涉及一个名词（代表变量或方法处理的事物），后面跟着提供附加上下文或指定操作的形容词或动词。
\n例如，Google Java 风格指南建议变量名称应该是简短的描述性名词或名词短语。使用此约定，您可以命名一个变量employeeNumber或totalWidth.
\n英语或其他口语的自然结构由于熟悉而对于大多数程序员来说往往更舒服。它反映了我们自然交流的方式。customerAccountNumber对于说英语的程序员来说比numberAccountCustomer，即使后者在语言意义上可能更一致。
在您的示例中，变量名称的自然英语版本通常更容易理解，因为它们遵循更熟悉的语言模式。名称的一致右分支版本虽然逻辑上一致，但解析起来有点困难，因为它们与英语的自然词序不匹配。
\n至于 OF 语言的 PRIME-MODIFIER-CLASS 单词方案，这确实代表了一种更一致的右分支命名方法，首先是更一般的类别 (CLASS)，然后是 MODIFIER，然后是 PRIME。但即使在这种情况下，约定的设计也是为了使代码更易于阅读和理解，而不是实现严格的语言一致性。
\n但是，您关于深度嵌套数据结构中出现的不一致的观点得到了很好的理解。对于复杂且深层嵌套的结构，语言上更加一致的命名约定确实可能有助于理解元素之间的关系。在需要来自不同语言背景的人理解代码的情况下，或者在处理特别复杂的数据结构时，这可能特别有用。
\n一般来说，最重要的因素是清晰度。如果特定的命名约定始终可以帮助您和您的团队更有效地理解您的代码，那么这是对其有利的有力论据。
\n但是，如果您在较大的开发社区中工作，则可能需要平衡您对一致命名方案的个人偏好与该社区的流行约定。
并且您需要考虑命名约定的另一个方面： context的使用。
\n将计算结果分配给变量时，名称的选择取决于变量在周围代码上下文中的用途。如果该变量用于在迭代客户列表的循环中存储当前帐号，则currentAccountNumber（或currAccNum为了简洁起见）是一个直观的名称，因为它简洁地解释了该变量的用途。
通常，有比简单地附加字母或数字更有意义的名称来区分相似的变量。例如，如果要比较的两个帐号分别属于交易的发送方和接收方，您可以将它们命名为senderAccountNumber和，这比和receiverAccountNumber提供更多上下文。accountNumberAaccountNumberB
您的示例（acctNoCustomerA/acctNoCustomerB或customerAAcctNo/customerBAcctNo或noAcctACustomer/noAcctBCustomer）强调了提出直观且可读的一致命名方案的挑战。虽然与acctNoCustomerA右分支方法更一致，但customerAAcctNo对许多开发人员来说可能更直观，因为它遵循英语名义结构。
一般来说，最佳实践是选择清晰、简洁且具有描述性的变量名称。一致性很重要，但不能以牺牲可读性或理解性为代价。
\n因此，虽然一致的左分支或右分支命名方案可能在语言上更正确，但它不一定是代码可读性的最佳选择，特别是对于习惯了类似英语的命名约定的开发人员来说。
\n另请参阅Miltiadis Allamanis、Earl T. Barr、Christian Bird 和 Charles Sutton 的“学习自然编码约定”。
\n它引用了 Samir Gupta、Sana Malik、Lori Pollock 和 K. Vijay-Shanker 的“程序标识符的词性标记，以改进基于文本的软件工程工具”（此处为 pdf）。
\n\n\n为了帮助程序理解，程序员主要通过遵循软件中的命名约定来选择方法、类、字段和其他程序元素的标识符。
\n
\n这些软件\xe2\x80\x9c命名约定\xe2\x80\x9d遵循系统模式，可以传达软件工程工具可以利用的深层自然语言线索。例如，它们可用于提高软件搜索工具的准确性，提高程序导航工具推荐相关方法的能力，以及提高其他程序分析的准确性。将多单词名称拆分为其组成单词后，提取准确的自然语言信息的下一步是用词性( POS )标记每个单词，然后将名称分块为自然语言短语。
\n最先进的方法大部分依赖于在自然语言文档上训练的传统词性标注器 xe2x80x9d，但不能捕获程序元素的句法结构。在本文中，我们提出了一种用于源代码名称的词性标注器和句法分块器，它考虑了程序员的命名约定，以理解程序元素命名的常规、系统方式。
\n
这些文章可以帮助您为您的研究提供信息。
\n关于OP的评论：
\n\n\n看来编程社区还没有详细考虑我的具体问题
\n
\n\n假设 的逻辑结构
\n[accounts[customers[a]].number]，一个真正完美的右分支名称可能是，反映了“ ”和“ ”紧密结合在一起的Acct_CustomerA_No层次结构，但“ ”并不直接连接到“ ”或“CustomerAAAcctNo”。
Acct_CustomerA_No在某些情况下可能更直观和可读，特别是在处理复杂的数据结构时。它是一种将相关元素直观地分组在一起的方法，类似于数学表达式中使用括号来显示运算顺序的方式。