代码如何“自我记录”而不令人烦恼？[关闭]

StackOverflow https://stackoverflow.com/questions/214160

  •  03-07-2019
  •  | 
  •  

题

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

冗长是否有助于可读性，还是只会伤害大家的眼睛？——人们是否更喜欢缩写和缩写名称而不是较长的名称？

有帮助吗？

解决方案

就个人而言，我更愿意看到更长的名字，这些名称实际上意味着某些东西而不必先确定上下文。当然，不具有实际意义的变量，例如计数器，我仍然使用小的无意义的变量名（例如 i 或 x ），否则在大多数情况下，冗长是清晰度。对于公共API尤其如此。

但是，这可能会走得太远。我在过去看过一些VB代码就太荒谬了。像其他一切一样适度！

其他提示

在所有现代IDE和texteditor完成后，我实际上一直使用长变量名，所以如果我使用 index 没有任何问题。我唯一的例外是处理坐标b / c x 和 y 在那里最有意义。

永远不会。

变量应该用尽可能短的名称来充分传达其目的。

过度冗长倾向于隐藏语法，语法很重要。

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

缩写（如果使用的话）应始终如一地应用于所有地方，如果特定于域，则应记录在某处。如果有人花费任何有用的时间在代码上，那么他们很快就会学习。

如果您需要组合多达五个或六个单词来命名变量，那么我建议您可能正在查看代码味道，你正在工作的例程可能会从一点点工作中受益。

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

1年后尝试阅读自己的代码。你会看到自我记录变量名的值，以及代码注释的值（特别是干净代码的值）

当你抓住别人的源代码并且你不理解它时，很容易思考“嗯，他不像我那样好的程序员”。但是当你意识到你自己的代码难以阅读时，你会说：“我认为是什么？”

从长远来看，详细程度有助于维护。对于简短的一行脚本，您仍然可以使用“setLocNm”。而不是setLocationName＆quot;

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

就我个人而言，我认为冗长是一件好事，但也很容易过于冗长，这是一件坏事。这是一种平衡，缩写也可以达到这种平衡。

这些是我的一般规则：

  • 迭代器可以是一个字母，即。 i, j, k, ， ETC。
  • 其他单字变量如布尔切换，你所拥有的永远不会缩写，即。 installing, done, ， ETC。
  • 多个单词变量和函数名称都可以使用缩写，但前提是它们开始变得非常长（例如 20-25 个以上字符）。智能缩写是这里的关键。 function => func 例如，但从来没有 fun, f, ， 或者 functi

我浏览了答案，但我不知道是否覆盖了以下内容。这就是......

无论你是缩写还是冗长，只要确保你没有使用过多于必要的词语，其含义就太明显了。

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

def initialize_report_template()
end

应该是...... 

class ReportTemplate
    def initialize()
    end
end

更长的名字要好得多。你提到你经常在小范围内看到缩写名称。谁能说随着软件的发展，范围仍然很小？

当然，XCoordinateForCurrentLocationOfSelf是一个荒谬的名字，所以才合情合理。特别是如果你正在进入一个你之前没有参与过的项目，你会感谢使用描述性函数和变量名的任何人。

我认为可以缩写名称是否会损害可读性或只是多余的。

示例1：类型allready传达所有必要信息的方法的参数。

示例2：将以显而易见的方式使用的变量

StringBuilder sb = ...
sb.append(...
sb.append(...
return sb.toString();

示例3：惯用语缩写。我，j，k已经提到了。 ＆QUOT; SB＆QUOT;上面是我们代码中的一个，每个团队可能还有一些。

目标是缩短而不是更长，但读者理解应该胜过 laziness to type 。

正如其他人所说，变量名称长度不应该模糊逻辑或算法。例如，在算术中，我们写

( 1 + 5 ) * 3 = 18

而不是

three multiplied by the sum of one and five equals eighteen

因为我们试图引起对其他事物的注意，而不是表达中涉及的元素的清晰度。

我倾向于将变量保留为一到三个单词，仅在我超过24个字符时才缩写。变量使用的频率越低，我就越有可能随意使变量名变长。更频繁使用的变量我会缩短。

Bugzilla的首席架构师Max Kanat-Alexander在他的博客上说：

  

代码本身应占据与其具有多少意义的空间。

     

基本上，微小符号表示a   很多代码难以阅读。很长   不太重要的名字   代码难以阅读。大量的   意义和占用的空间应该   彼此密切相关。

http://www.codesimplicity.com/post/readability-and -naming-东西/

这是关于命名事物的非常有见地的帖子。我敦促大家阅读！

我唯一接受缩写的是局部变量，这些变量只在很短的时间内使用。

意味着他们应该使用非常易读的方法或构造函数进入范围。

我同意Kilhoffer;我更喜欢在几乎每个上下文中都看到描述性变量名。如果我的变量名长度大于20个字符，我会缩写，通常使用变量名中的单词（例如：“SomeVeryLongVarValue”）。

当然，我也尽可能使用匈牙利语表示法，所以我很可能会在另一个极端阵营中试图让我的变量名称过于描述，这取决于你的观点。

我可能会被完全嘘声，但我想确保听到这种观点。

虽然较长的变量名称可能更具描述性，但它们可能会开始影响程序的原始意图。我觉得在API元素上，在上下文中使用明确且有意义的名称非常重要。

在每个功能或方法中，这通常是一个不同的故事。我试着少写，并保持非常简洁。这被称为斯巴达编程，如 Mr. Atwood 和这个漂亮的例子。是的，这个例子显然是被操纵的，但它确实证明了如何让一点点的仪式更容易让阅读程序更容易。

祝你好运。

编程时，你正在使用语法，以便人类可以读取它，变量名称，方法等的长度......实际上是无关紧要的。

通常越好越好，在良好的开发环境中你应该完成代码，所以你只需点击“add_L”+ + TAB即可完成方法调用。

我认为缩写的主要问题是并非所有人都以相同的方式缩写，因此当您与许多人合作时，它只会增加编码时出错的可能性。例如，如果你有一个可以被称为SOMETHING_INTERFACE的常量，也许一些开发人员将其缩写为SOMETHING_INTFACE，其他人将其缩写为SOMETHING_IFACE或SOMETHING_IF，SMTHING_IFACE ......

只有两个单词，你可以拥有至少六个或多或少的“逻辑”字样。可能的缩写，所以我认为在大多数情况下，如果你想要自己编写代码，那么在没有缩写的情况下编写更好，并且有更多理由。

很长的名字有时会很烦人，但也可以使用辅助变量在非常局部的范围内缩写。

大多数人看到了视频，不再需要阅读一个单词然后阅读单个字母。总是使用有意义的名字。他们必须完整的7个字的描述，不，但他们需要更长的时间来理解。

我可以接受add_loc（name，coord），因为它们足够长，我可以告诉它们是什么。在add_loc（n，x，y）中，我会反对'n'而不是name。我可以使用X和Y，因为这些是公认的坐标名称。

对于不熟悉坐标系的人，我可以看到add_location（名称，坐标）更有意义。

如有疑问，请使用较长的名字。

“可以搞清楚谋杀之谜，但你不应该弄清楚代码。你应该能够阅读它。“ - Steve C. McConnell

也就是说，如果您认为您或其他任何人都需要过于明确的变量名等，请随意缩短它们。

我建议采取极简主义的做法。尽可能少地使用，同时确保您的代码保持清晰，简洁和重要。

超出范围的事情，如常量和全局变量，应该有很长的描述性名称。有时一个很长的名字会使它“闻”到足以表明它的存在是不必要的。这是一件好事，因为它会让人们避开它，2 - 增加压力来重构代码以使其消失。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top