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