如何“自我logging”可以编码而不恼人？
我不确定最佳实践在这里，但是我经常会看到缩写的variables名，特别是当范围很小的时候。 所以（使用简单的Ruby示例）而不是def add_location(name, coordinates) ，我看到了诸如def add_loc(name, coord)东西 – 我甚至可能会看到类似def add_loc(n, x, y) 。 我想象一下，当他们习惯于看缩写词的时候，更长的名字可能会使人厌倦。
冗长是否有助于可读性，还是只是伤害了每个人的眼睛？人们更喜欢缩写和缩短的名字，而不是更长的名字？
就个人而言，我宁愿看到更长的名称，实际上意味着什么，而不必首先确定上下文。 当然，不能提供真正含义的variables，如计数器，我仍然使用小的无意义的variables名（例如i或x ），但是其他的冗长性在大多数情况下是清晰的。 公共API尤其如此。
但是，这可能会花费太多。 过去我曾经见过一些VB代码，这太荒谬了。 像其他一切一样适度！
我实际上总是使用长variables名，毕竟现代IDE和文本编辑器已经完成了，所以如果使用index没有什么问题。 我唯一的例外是处理坐标b / c x和y在那里最有意义。
永远不要缩写。
应该给一个variables尽可能短的名字，以充分expression其目的。
过于冗长往往隐瞒语法，语法很重要。
在整个程序（或应用程序/系统）中，应该用一致的风格来命名variables，类似的事物应该被命名为相似的。 如果语言社区中存在惯例，除非有一些令人信服的理由不这样做，否则应该遵守（所以不要使用camelCaseRubyVariableNames）。
缩略语（如果使用的话）应该在任何地方一致地应用，并且如果特定领域的话应该被logging在某处。 如果有人要花时间在代码上，那么他们很快就会学习。
如果你需要结合多达五六个字来命名一个variables，那么我build议你可能正在看一个代码的气味 ，你正在工作的例程可能会从一个小小的工作中受益。
但是，大多数情况下，如果你意识到陷阱，并且真正想到你正在写什么，那么你的代码很可能是合理的。 想象一下，你自己描述你正在为一个新同事工作的function – 你认为你需要说的越less，代码就越好。
尝试在1年后阅读您自己的代码。 您将看到自我loggingvariables名称的值，以及代码注释的值（特别是干净代码的值）
当你抓别人的源代码，你不明白这一点时，很容易想到“那么他不像我这样好的程序员”但是当你意识到自己的代码很难阅读时，你会这样想：“我是什么thinkng？”
从长远来看，详细信息有助于可维护性。 对于简短的一行脚本，仍然可以使用“setLocNm”而不是setLocationName“
任何傻瓜都可以编写计算机可以理解的代码。 好的程序员编写人类可以理解的代码。 马丁福勒
就个人而言，我发现冗长是一件好事，但也很容易过于冗长，这是一件坏事。 有一个平衡，缩写也可以达到这个平衡。
这是我的一般规则：
- 迭代器可以是一个字母，即。
i，j，k等 - 其他一个字variables像布尔切换，你从来没有缩写，即。
installing，done等 - 多个单词variables和函数名称是缩写的候选对象，但只有当它们开始变得很长时（比如说20-25个字符）。 智能缩写是关键。
function => func例如，但从来没有fun，f，或function
我浏览了答案，但我不知道是否涵盖以下内容。 这里呢…
无论你是缩写还是冗长，只要确保你没有使用更多的词语，意义就显而易见了。
但即使在过滤之后，如果您的标识符看起来很冗长，那么您的devise中就有一个缺陷。
def initialize_report_template() end
本来应该…
class ReportTemplate def initialize() end end
更长的名字好多了。 你提到你经常在小范围内看到缩写名称。 谁能说随着软件的发展，这个范围将会保持很小？
当然，XCoordinateForCurrentLocationOfSelf是一个荒谬的名字，所以才是合理的。 特别是如果你正在进入一个你以前从未使用过的项目，那么你会感谢所有使用描述性函数和variables名的人。
我认为缩写名称会伤害可读性或冗余是可以的。
示例1：一个方法的参数，其中typesallready传达所有必要的信息。
例2：一个variables，将以一个明显的方式使用很多
StringBuilder sb = ... sb.append(... sb.append(... return sb.toString();
例3：习语缩写。 我，j，k已经被提及。 上面的“sb”是我们代码中的一个，每个团队可能还有更多。
目的是缩短而不是延长，但读者的理解应该每一次都要打败懒惰 。
正如其他人所说，variables名称长度不应该掩盖逻辑或algorithm。 例如，在算术中，我们写
( 1 + 5 ) * 3 = 18
而不是
three multiplied by the sum of one and five equals eighteen
因为我们试图把注意力吸引到其他事情上，而不是expression中涉及的元素的清晰度。
我倾向于把variables保留一到三个字，只有当我超过24个字符左右时才缩写。 variables被使用的频率越低，我越容易随意使variables名变长。 更常用的variables我会缩短。
Bugzilla首席架构师Max Kanat-Alexander在他的博客上说：
代码本身应该占据空间的比例，它有多less意义。
基本上，意味着很多的小符号使代码难以阅读。 非常长的名字并不意味着太多也使代码难以阅读。 意义的数量和占用的空间应该密切相关。
http://www.codesimplicity.com/post/readability-and-naming-things/
这是一个很有见地的事情。 我呼吁大家阅读它！
我接受缩写的唯一时间是局部variables，只在一段时间内才有效。
意味着他们应该进入一个非常可读的方法或构造函数的范围。
我同意Kilhoffer; 我更喜欢在几乎所有的上下文中看到描述性的variables名称。 如果我的variables名长于20个字符左右，通常用variables名中的单词（例如：“SomeVeryLongVarValue”）来缩写。
当然，我也会尽可能使用匈牙利符号，所以我可能会在另一个极端的阵营，试图使我的variables名称过度描述，取决于你的观点。
我可能会完全嘘，但我想确保这个观点被听到。
尽pipe较长的variables名称可能更具描述性，但是它们可能开始使程序的原意变得沉闷。 我觉得对于API元素来说，在他们将要使用的上下文中有明确而有意义的名字是很重要的。
在每个function或方法中，这往往是一个不同的故事。 我尽量less写，保持简洁。 这就是所谓的阿斯特伍德先生的斯巴达编程和这个漂亮的例子。 是的，这个例子显然是操纵的，但它确实certificate了less一点仪式实际上可以使程序更容易阅读。
祝你好运。
编程时，你正在使用的语法，以便人类可以阅读，variables名称，方法等的长度真的不相关的。
通常越好越好，在一个好的开发环境下，你应该有代码完成，所以你可以简单地点击“add_L”+ TAB来完成方法调用。
我认为缩写的主要问题是不是所有的人都用同样的方式缩写 ，所以当你和很多人一起工作时，只会增加编码时出错的几率。 例如，如果你有一个常量，可以被称为SOMETHING_INTERFACE，也许一些开发人员会缩写为SOMETHING_INTFACE，其他人SOMETHING_IFACE或SOMETHING_IF，SMTHING_IFACE …
只用两个单词就可以有至less六十多个或更less的“逻辑”可能的缩写，所以我认为在大多数情况下，如果您想要自行编写代码，没有缩写和更多的原因。
很长的名字有时候可能会很烦人，但是也可以在使用辅助variables的本地范围内缩写。
大多数人的视线都是阅读，不再读一个字，然后读一个字母。 所以总是使用有意义的名字 他们必须完整的7个字的描述，不，但他们需要更长的时间来理解。
我可以接受add_loc（name，coord），因为它们足够长，我可以告诉它们是什么。 在add_loc（n，x，y）中，我反对'n'而不是名字。 我可以和X和Y一起生活，因为这些是可以接受的坐标名称。
对于不熟悉坐标系的人，我可以看到add_location（name，coordinate）会更有意义。
如有疑问，请使用更长的名字。
“找出谋杀的奥秘是可以的，但是你不需要弄清代码，你应该可以阅读。 – Steve C. McConnell
也就是说，如果你认为你和其他人都不需要过于明确的variables名等等，可以随意缩短它们。
我build议采取极简主义的方法。 尽可能使用一点点，同时确保您的代码保持清晰，简洁并符合要求。
超出范围的东西，如常量和全局variables应该有很长的描述性名称。 有时一个真正长的名字会使它“闻”到足以表明它的存在是不需要的。 这是一件好事，因为它会使人们避免它，2 – 增加压力重构代码使其消失。
