I'm currently writing a very simple start to a test tool. The idea is that you can have classes that include my "Testable" module. For example:
class Veilus
include Testable
end
site = Veilus.new
The Testable module has the following:
module Testable
module_function
def included(caller)
caller.extend Testable::Interface::Page::Attribute
caller.__send__ :include, Testable::Interface::Page
end
end
When Reek checks out this file, it returns:
FeatureEnvy: Testable#included refers to 'caller'
more than self (maybe move it to another class?)
But isn't that one of the points of the included method?
I realize that I can turn this aspect of Reek checking off but I'm curious exactly how I would go about following its advice here? The class, in this case, is not something I'll know about a head of time. Classes that other people write will include my module.
Again, I know I can turn off the check but it seems like I might want the check in other contexts. So then I started to wonder if perhaps I'm doing the "mixin" approach wrong and that's what Reek is pointing out.
I found one way to "handle" this, which is essentially to just use
self
to reference theincluded
call. So, for example, I could do this:What I did was change my above code such that the call to
module_function
is no longer used. (Although that does run afoul of some other style guide rules.) Then I just usedself.
in front of theincluded
message.When I do that, the FeatureEnvy warning no longer occurs. This seems like a pretty weak way for the FeatureEnvy condition to be flagged, to be honest.
This, along with various other issues, has convinced me not to use Reek and just stick with Rubocop. (I realize they are, in many cases, looking at very different things.) I would not advocate this approach for enterprise-type development but in terms of writing test tools, I find you actually do a lot of "clever" things that checkers like Reek just don't like.