Question

我在我的项目上运行rubocop并修复它引发的抱怨。

一个特别的抱怨困扰着我

Do not prefix reader method names with get_

我对这个投诉无法理解，所以我看了source code in github。

我找到了这个代码段

    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_。否则他们允许得到_

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

这项公约或规则或建议背后的原因是什么？

Answer 1

我认为这里的重点是ruby devs更喜欢将方法视为getter，因为它们返回一些内容并使用等于“syntactic sugar”（如def self.dog=(params)中允许你执行Class.dog = something）。从本质上讲，我一直看到的一点是get和set是冗余和冗长的。

与此相反，你已经获得并设置了多个args，就像finder方法一样（特别是get;想想ActiveRecord的where）。

请记住'风格指南'=纯粹的意见。一致性是一般风格指南的更高目标，所以除非某些东西可以说是错误的或难以阅读，否则你的目标应该是让所有东西都与某种类型相同。这就是为什么rubocop让你关闭它。

Answer 2

另一种看待它的方法：据我所知，getter / setter范例主要是Java / C ++等中的特定约定。至少我知道很多Java代码库在过去非常模糊的过程中，Beans充斥着大量的get_-getters和set_-setter。在那个时候，private属性可能被称为“name”，带有“set_name（）”和“get_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的商标。： - ）

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

2 个答案: