为什么 rubocop 或 ruby​​ 风格指南不喜欢使用 get_ 或 set_？

Question

我在我的项目上运行 rubocop 并解决它提出的投诉。

一个特别的抱怨困扰着我

Do not prefix reader method names with get_

我对这个投诉不太了解，所以我查看了source code in github。

我找到了这个sn-p

    def bad_reader_name?(method_name, args)
      method_name.start_with?('get_') && args.to_a.empty?
    end

    def bad_writer_name?(method_name, args)
      method_name.start_with?('set_') && args.to_a.one?
    end

所以建议或约定如下：

1) 实际上，他们建议我们在方法没有参数时不要使用 get_ 。否则他们允许get_

2) 当方法只有一个参数时，他们建议我们不要使用 set_ 。否则他们允许 set_

这个约定、规则或建议背后的原因是什么？

Answer 1

我认为这里的重点是 ruby​​ 开发人员更喜欢始终将方法视为 getter，因为它们返回一些内容并使用等于“语法糖”（例如在 def self.dog=(params) 中，它可以让您执行 Class.dog = something）。从本质上讲，我一直看到的观点是 get 和 set 是多余且冗长的。

与此相反，您可以使用多个参数获取和设置，这些参数类似于查找器方法（特别是 get；想想 ActiveRecord 的 where）。

请记住，“风格指南”= 纯意见。一般来说，一致性是样式指南的更高目标，因此除非某些内容可以说是错误的或难以阅读，否则您的目标应该更多是让所有内容都相同而不是某种类型。这就是为什么 rubocop 让你把它关掉。

Answer 2

另一种看待它的方式：据我所知，getter/setter 范式在很大程度上是 Java/C++ 等中的特定约定；至少我在非常模糊的过去知道相当多的 Java 代码库，其中 Bean 散布着大量的 get_-getter 和 set_-setter。在那个时候，私有属性可能会被称为“name”，带有“set_name()”和“get_name()”；由于属性本身被称为“name”，getter 也不能是“name()”。

因此，“get_”和“set_”的存在是由于不允许在方法名称中使用“=”的语言的（微不足道的）技术缺陷。

在 Ruby 中，我们有很多不同的可能性：

• 首先，我们有name() 和name=()，它立即消除了对get_ 和set_ 语法的需求。所以，我们确实有 getter 和 setter，只是我们对它们的称呼与 Java 不同。

• 另外，属性不是name而是@name，因此也解决了这个冲突。

• 实际上，您根本没有使用简单的“obj.name”语法的属性！例如；虽然 Rails/ActiveRecord 假装“person.name”是一个“属性”，但实际上它只是一对自动生成的 getter name() 和 setter name=()。从概念上讲，调用者不应该关心“名称”是什么（属性或方法），它是类的实现细节。

• 每次通话可节省 4 或 3 次按键。这似乎是个笑话，但编写简洁但易于理解的代码毕竟是 Ruby 的商标。 :-)