我不确定这里的最佳实践是什么，但我经常看到缩写的变量名，尤其是在范围很小的时候。所以（使用简单的 Ruby 示例）我看到的不是def add_location(name, coordinates)，而是def add_loc(name, coord) 之类的东西——我什至可能看到def add_loc(n, x, y) 之类的东西。 我想当一个人习惯于看到缩写时，更长的名字可能会让他们厌倦。
冗长有助于可读性，还是只会伤害每个人的眼睛？——人们更喜欢缩写和缩短的名称而不是较长的名称吗？
【问题讨论】：
标签： ruby documentation readability
就我个人而言，我宁愿看到更长的名称实际上意味着某些东西，而不必先确定上下文。当然，不赋予真正意义的变量，比如计数器，我还是用小的无意义的变量名（比如i或x），但除此之外冗长就是清晰时间。公共 API 尤其如此。
但是，这可能太过分了。过去我曾见过一些 VB 代码那样荒谬。像其他一切一样适度！
【讨论】：
永远不要缩写。
【讨论】：
实际上，我一直都使用长变量名，毕竟现代 IDE 和文本编辑器都已完成，所以使用 index 代替 i 没有任何问题。我唯一的例外是在处理坐标 b/c x 和 y 时最有意义。
【讨论】：
应为变量指定尽可能短的名称，以充分表达其用途。
冗长往往会掩盖语法，而语法很重要。
在整个程序（或应用程序/系统）中，变量应该以一致的风格命名，相似的事物应该以相似的方式命名。如果语言社区中存在约定，则应遵守（所以不要使用 camelCaseRubyVariableNames），除非有令人信服的理由不这样做。
如果使用缩写词，则应在任何地方一致地应用，如果是针对特定领域的，则应记录在某处。如果有人打算在代码上花费任何有用的时间，那么他们很快就会学会。
如果您需要组合多达五个或六个单词来命名一个变量，那么我建议您可以查看code smell，您正在工作的例程可能会从一些工作中受益。
不过，大多数情况下，如果您意识到其中的缺陷并真正思考您正在编写的内容，那么您的代码很可能是合理的。想象一下，你向一位新同事描述你正在开发的功能 - 你认为你需要说的越少，代码可能就越好。
【讨论】：
尝试在 1 年后阅读您自己的代码。您将看到自我记录变量名称的值和代码 cmets 的值（特别是干净代码的值）
当您获取别人的源代码并且您不理解它时，很容易认为“他不像我那么优秀的程序员”但是当您意识到自己的代码很难阅读时，您会这样：“我在想什么？”
从长远来看，冗长有助于可维护性。对于简短的一行脚本，您仍然可以使用“setLocNm”而不是 setLocationName”
任何傻瓜都可以编写计算机可以理解的代码。优秀的程序员编写人类可以理解的代码。 -Martin Fowler
【讨论】：
就我个人而言，我觉得冗长是件好事，但也很容易过于冗长，这是一件坏事。有一个平衡，缩写也可以达到平衡。
这些是我的一般规则：
i、j、k等installing、done等function => func，但绝不是fun、f 或functi
【讨论】：
我浏览了答案，但不知道是否涵盖了以下内容。就这样吧……
无论你是缩写还是冗长，只要确保你没有使用不必要的单词并且意思很明显。
但即使经过过滤，如果你的标识符看起来很冗长，你的设计就有缺陷。
def initialize_report_template()
end
应该是……
class ReportTemplate
def initialize()
end
end
【讨论】：
名字越长越好。您提到您经常在小范围内看到缩写名称。谁能说随着软件的增长，范围仍然很小？
当然，XCoordinateForCurrentLocationOfSelf 是一个荒谬的名字，所以请保持合理。尤其是当你走进一个你以前没有参与过的项目时，你会感谢任何使用描述性函数和变量名的人。
【讨论】：
我认为当名称会损害可读性或只是多余时，可以缩写。
示例 1：类型已经传达所有必要信息的方法的参数。
示例 2：一个明显会被大量使用的变量
StringBuilder sb = ...
sb.append(...
sb.append(...
return sb.toString();
示例 3：惯用缩写。 i,j,k 已经被提及。上面的“sb”是我们代码中的一个，每个团队可能还有几个。
【讨论】：
database = Sequel.new(...)，但我不介意常见的例子DB = Sequel.new(...)
力求更短而不是更长，但读者的理解应该每次都胜过laziness to type。
正如其他人所说，变量名称长度不应掩盖逻辑或算法。例如，在算术中，我们写
( 1 + 5 ) * 3 = 18
而不是
three multiplied by the sum of one and five equals eighteen
因为我们试图将注意力吸引到表达中所涉及元素的清晰度之外的其他事情上。
我倾向于将变量保留为一到三个单词，仅当我超过 24 个字符左右时才缩写。变量使用的频率越低，我就越有可能随意将变量名变长。更常用的变量我会缩短。
【讨论】：
Bugzilla 的首席架构师 Max Kanat-Alexander 在他的博客上这样说：
代码本身占用的空间应该与它的含义成正比。
基本上，小符号表示 很多使代码难以阅读。很长 意义不大的名字也会使 代码难以阅读。大量的 意义和占用的空间应该 密切相关。
http://www.codesimplicity.com/post/readability-and-naming-things/
这是一篇关于命名事物的非常有见地的帖子。我敦促大家阅读它！
【讨论】：
我唯一接受缩写的情况是用于仅在一小段时间范围内的局部变量。
意味着它们应该以非常易读的方法或构造函数进入范围。
【讨论】：
我同意基尔霍夫的观点；我更喜欢在几乎所有上下文中看到描述性变量名称。如果我的变量名超过 20 个字符左右，我会缩写，通常在变量名中使用单词（例如：“SomeVeryLongVarValue”）。
当然，我也尽可能使用匈牙利符号，所以我很可能属于另一个极端阵营，试图让我的变量名称过于描述性，这取决于你的观点。
【讨论】：
我可能会完全被嘘，但我想确保听到这个观点。
虽然较长的变量名称可以更具描述性，但它们可能会开始陷入程序的原始意图。我认为在 API 元素上，在使用它们的上下文中具有清晰且有意义的名称非常重要。
在每个函数或方法中，这通常是不同的故事。我尽量少写，保持简洁。这在Mr. Atwood 和this 漂亮的例子中被称为spartan 编程。是的，这个例子显然是被操纵的，但它确实证明了少一点仪式实际上可以使阅读程序更容易。
祝你好运。
【讨论】：
在编程时，您使用的是人类可以阅读的语法，变量名称、方法等的长度确实无关紧要。
通常越详细越好，在良好的开发环境下，无论如何你都应该有代码完成，所以你可以简单地点击“add_L”+TAB来完成方法调用。
【讨论】：
我认为缩写的主要问题是并非所有人都以相同的方式缩写，所以当你与很多人一起工作时，它只会增加编码时出错的可能性。例如，如果您有一个可以称为 SOMETHING_INTERFACE 的常量，可能一些开发人员会将其缩写为 SOMETHING_INTFACE，其他人会缩写为 SOMETHING_IFACE 或 SOMETHING_IF、SMTHING_IFACE...
只有两个词你可以有至少六个或多或少的“逻辑”可能的缩写，所以我认为在大多数情况下最好不要缩写，如果你想拥有更多的理由- 文档化代码。
有时很长的名字会让人讨厌，但也可以在非常局部的范围内使用辅助变量进行缩写。
【讨论】：
大多数人视读，阅读一个单词不再需要阅读单个字母。所以总是使用有意义的名字。它们是否必须是完整的 7 个单词描述，不，但它们需要足够长才能理解。
我可以接受 add_loc(name, coord)，因为它们足够长，我可以分辨它们是什么。在 add_loc(n, x, y) 中，我会反对“n”而不是名称。我可以接受 X 和 Y，因为它们是公认的坐标名称。
对于不熟悉坐标系的人，我可以看到 add_location(name, coordinates) 在哪里更有意义。
如有疑问，请使用更长的名称。
【讨论】：
“弄清楚谋杀之谜是可以的，但你不应该需要弄清楚代码。你应该能够阅读它。”——Steve C. McConnell
也就是说，如果您认为您或其他任何人都需要过于明确的变量名称等，请随意缩短它们。
【讨论】：
我建议采取极简主义的方法。尽量少用，同时确保您的代码保持清晰、简洁和重点。
【讨论】：
像常量和全局变量这样的超出范围的东西应该有很长的描述性名称。有时，一个很长的名字会让它“闻起来”，足以表明它的存在是不受欢迎的。这是一件好事，因为它会 1 - 让人们避免它，2 - 增加重构代码以使其消失的压力。
【讨论】：