我不确定这里的最佳实践是什么，但我经常看到缩写的变量名，尤其是在范围很小的时候。所以（使用简单的 Ruby 示例）而不是def add_location(name, coordinates)，我看到类似的东西def add_loc(name, coord)——我什至可能看到类似的东西def add_loc(n, x, y)。我想当一个人习惯于看到缩写时，较长的名字可能会让他们感到厌烦。
冗长是否有助于可读性，还是只会伤害每个人的眼睛？——人们更喜欢缩写和缩短的名字而不是更长的名字吗？
就个人而言，我宁愿看到更长的名字，实际上意味着什么，而不必先确定上下文。当然，对于没有真正意义的变量，例如计数器，我仍然使用小的无意义的变量名称（例如ior x），但大多数时候冗长是清晰的。公共 API 尤其如此。
然而，这可能太过分了。过去我曾见过一些 VB 代码那样荒谬。像其他一切一样适度！
永远不要缩写。
实际上，我一直使用长变量名，毕竟现代 IDE 和文本编辑器都已完成，因此使用indexif i. 我唯一的例外是在处理坐标 b/cx并y在那里最有意义时。
变量应该被赋予尽可能短的名称，以充分表达其目的。
过于冗长往往会掩盖语法，而语法很重要。
在整个程序（或应用程序/系统）中，变量应该以一致的风格命名，类似的东西应该以类似的方式命名。如果语言社区中存在约定，则应遵守（所以不要使用 camelCaseRubyVariableNames），除非有令人信服的理由不这样做。
缩写，如果使用，应该在任何地方一致地应用，如果是特定领域的，应该记录在某个地方。如果有人打算在代码上花费任何有用的时间，那么他们很快就会学会。
如果您需要组合多达五个或六个单词来命名一个变量，那么我建议您可能正在查看代码气味，并且您正在工作的例程可能会受益于一些工作。
但是，大多数情况下，如果您意识到这些陷阱并真正考虑您正在编写的内容，那么您的代码很可能是合理的。想象一下你自己向一位新同事描述你正在开发的功能——你认为你需要说的越少，代码可能就越好。
尝试在 1 年后阅读您自己的代码。您将看到自我记录变量名称的值和代码注释的值（特别是干净代码的值）
当你获取别人的源代码并且你不理解它时，很容易认为“他不像我那样优秀的程序员”但是当你意识到你自己的代码很难阅读时，你会想：“我是什么？想？”
从长远来看，冗长有助于可维护性。对于简短的一行脚本，您仍然可以使用“setLocNm”而不是 setLocationName”
任何傻瓜都可以编写计算机可以理解的代码。优秀的程序员编写人类可以理解的代码。 ——马丁·福勒
就个人而言，我发现冗长是件好事，但也很容易过于冗长，这是一件坏事。有一种平衡，缩写也可以达到这种平衡。
这些是我的一般规则：
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”是我们代码中的一个，每个团队可能还有几个。
目标是更短而不是更长，但读者的理解应该胜过每次打字的懒惰。
正如其他人所说，变量名称长度不应混淆逻辑或算法。例如，在算术中，我们写
( 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”）。
当然，我也尽可能使用匈牙利符号，所以我很可能属于另一个极端阵营，试图让我的变量名称过于描述性，这取决于你的观点。
在编程时，您使用语法以便人类可以阅读它，变量名称、方法等的长度确实无关紧要。
通常越详细越好，在良好的开发环境下，无论如何您都应该有代码完成功能，因此您只需点击“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) 在哪里更有意义。
如有疑问，请使用更长的名称。
“弄清楚谋杀之谜是可以的，但你应该不需要弄清楚代码。你应该能够阅读它。” ——史蒂夫·C·麦康奈尔
也就是说，如果您认为您或其他任何人都需要过于明确的变量名称等，请随意缩短它们。
我建议采取极简主义的方法。尽量少用，同时确保你的代码保持清晰、简洁和中肯。
超出范围的东西，如常量和全局变量应该有很长的描述性名称。有时，一个很长的名字会让它“闻起来”，足以表明它的存在是不受欢迎的。这是一件好事，因为它会 1 - 使人们避免它， 2 - 增加重构代码以使其消失的压力。