"自我记录"如何编码而不会烦人？

Question

我不确定这里的最佳实践是什么,但我经常看到缩写变量名称,尤其是当范围很小时.所以(使用简单的Ruby示例)而不是def add_location(name, coordinates),我看到类似的东西def add_loc(name, coord)- 我甚至可能会看到类似的东西def add_loc(n, x, y).我想,当他们习惯于看到缩写词时,较长的名字可能会让一个人厌倦.

冗长是否有助于提高可读性,还是只会伤害每个人的眼睛？ - 人们更喜欢缩写和缩短名称吗？

Answer 1

就个人而言,我更愿意看到更长的名字,实际上意味着什么,而不必先确定上下文.当然,不具有实际意义的变量,例如计数器,我仍然使用小的无意义的变量名称(例如i或x),但在大多数情况下其他详细程度是清晰的.对于公共API尤其如此.

然而,这可能会走得太远.我在过去看过一些VB代码就太荒谬了.像其他一切一样适度!

Answer 2

实际上,在所有现代IDE和texteditor完成之后,我实际上一直使用长变量名,因此使用indexif而不是没有错.我唯一的例外是处理坐标b/c x并y在那里最有意义.

Answer 3

永远不要.

Answer 4

应该给变量赋予最短的名称,以充分传达其目的.

过度冗长倾向于隐藏语法,语法很重要.

在整个程序(或应用程序/系统)中,变量应以一致的样式命名,类似的东西应该以相似的名称命名.如果语言社区中存在约定,则应该观察它(因此不要使用camelCaseRubyVariableNames),除非有一些令人信服的理由不这样做.

缩写(如果使用的话)应始终如一地应用于所有地方,如果特定于域,则应记录在某处.如果有人要花费任何有用的时间与代码,那么他们很快就会学到.

如果您需要组合多达五到六个单词来命名变量,那么我建议您可能会查看代码气味,而您正在工作的例程可能会从一些小工作中受益.

但是,大多数情况下,如果您意识到了陷阱并且实际考虑了您正在编写的内容,那么您的代码可能是合理的.想象一下,你自己正在向新同事描述你所做的功能 - 你认为你需要说的越少,代码可能就越好.

Answer 5

1年后尝试阅读您自己的代码.您将看到自我记录变量名称的值,以及代码注释的值(特别是干净代码的值)

当你抓住别人的源代码并且你不理解它时,很容易想到"好吧他不像我那样好"但是当你意识到你自己的代码难以阅读时你会说:"我是什么意思thinkng？"

从长远来看,冗长有助于维护.对于简短的一行脚本,您仍然可以使用"setLocNm"而不是setLocationName"

任何傻瓜都可以编写计算机可以理解的代码.优秀的程序员编写人类可以理解的代码. -Martin Fowler

Answer 6

就个人而言,我觉得冗长是一件好事,但也很容易过于冗长,这是一件坏事.有一个平衡点,缩写也可以达到平衡.

这些是我的一般规则:

• 迭代器可以是一个字母,即.i,j,k,等.
• 其他一个单词变量,如布尔切换,你从来没有缩写,即.installing,done等等.
• 多个单词变量和函数名称是缩写的候选者,但只有当它们开始变得冗长时(例如,20-25个字符).智能缩写是这里的关键.function => func例如,但从来没有fun,f或functi

Answer 7

我浏览了答案,但我不知道是否覆盖了以下内容.在这里......

无论你是缩写还是冗长,只要确保你没有使用过多于必要的词语,其含义就显而易见了.

但即使在过滤后,如果您的标识符看起来很冗长,那么您的设计中就存在缺陷.

def initialize_report_template()
end

本来应该...

class ReportTemplate
    def initialize()
    end
end