Why does rubocop or the ruby style guide prefer not to use get_ or set_?

Question

I was running rubocop on my project and fixing the complaints it raised.

One particular complaint bothered me

Do not prefix reader method names with get_

I could not understand much from this complaint so I looked at source code in github.

I found this snippet

    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

So the advice or convention is as follows:

1) Actually they advice us not to use get_ when the method does not have arguments . otherwise they allow get_

2) And they advice us not to use set_ when the method has only one argument .otherwise they allow set_

What is the reason behind this convention or rule or advice?

Answer 1

I think the point here is ruby devs prefer to always think of methods as getters since they returns something and use the equals "syntactic sugar" (like in def self.dog=(params) which lets you do Class.dog = something). In essence the point I've always seen made is that the get and set are redundant and verbose.

In opposition to this you have get and set with multiple args which are like finder methods (particularly get; think of ActiveRecord's where).

Keep in mind that 'style guide' = pure opinion. Consistency is the higher goal of style guides in general so unless something is arguably wrong or difficult to read, your goal should be more on having everything the same than of a certain type. Which is why rubocop let's you turn this off.

Answer 2

Another way to see it: the getter/setter paradigm was, as far as I can tell, largely a specific convention in Java/C++ etc.; at least I knew quite a few Java codebases in the very foggy past where Beans were littered with huge amounts of get_-getters and set_-setters. In that time, the private attribute would likely be called "name" with "set_name()" and "get_name()"; as the attribute itself was called "name", the getter could not be "name()" as well.

Hence the very existence of "get_" and "set_" is due to a (trivial) technical shortcoming of languages that do not allow the "=" in method names.

In Ruby, we have quite a different array of possibilities:

• First and foremost, we have name() and name=(), which immediately removes the need for the get_ and set_ syntax. So, we do have getters and setters, we just call them differently from Java.

• Also, the attribute then is not name but @name, hence solving this conflict as well.

• Actually, you don't have attributes with the plain "obj.name" syntax at all! For eaxmple; while Rails/ActiveRecord pretends that "person.name" is a "attribute", it is in fact simply a pair of auto-generated getter name() and setter name=(). Conceptionally, the caller is not supposed to care about what "name" is (attribute or method), it is an implementation detail of the class.

• It saves 4 or 3 key presses for each call. This might seem like a joke, but writing concise yet easily comprehensible code is a trademark of Ruby, after all. :-)