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

Question

我在我的项目上运行rubocop并修复它提出的抱怨.

一个特别的抱怨困扰着我

Do not prefix reader method names with get_

我从这个投诉中无法理解,所以我查看了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_.否则他们允许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次按键.这可能看起来像一个笑话,但写简明而易于理解的代码是红宝石的商标,毕竟.:-)