I was recently stumbling upon the Rubocop rule Style/PredicateName which
complained about predicate methods starting with has_ (e.g.
Human#has_children?).
Bozhidar Batsov (developer of Rubocop) explained that the rule was
based on a comment
made by Matz here:
"The basic naming for methods in standard class libraries are:
* use basic form (include not includes)
* put question mark for predicates
* put bang mark for "dangerous" version of methods
"is_a" and "has_key" are exceptions. "is_a" (or "isa") used very often
for inheritance in OO context.
"has_key" has already been deprecated by "key?"
"
I was wondering if this was really ment to ban has_ in predicate names.
In the example above I think it makes more sense to name the predicate #has_childen? instead of just #children?.
RSpecs language features underline my claim. When using has_ I can
write specs like this:
expect(father).to have_children
While without has_ this can only be written like this:
expect(father).to be_children
or
expect(father.children?).to eq true
A workaround is to name it #with_children? to spec it with
For me the reasoning is that has_ is redundant. What else could `children?`
mean?
Brevity is the soul of ruby
with_ will surprise others. If you don't agree with Rubocop I think it's
better to disable the rule in your .rubocop.yml.
I think 'expect(father.children?).to eq(true)' is ok, maybe not as
satisfying as have_children but still readable. Better to have good code
than good tests.
Regards,
Doug Hammond
···
On Fri, 23 Oct 2015 at 10:03 Kai Lehmann <kai@obfusco.de> wrote:
I was recently stumbling upon the Rubocop rule Style/PredicateName which
complained about predicate methods starting with has_ (e.g.
Human#has_children?).
Bozhidar Batsov (developer of Rubocop) explained that the rule was
based on a comment
made by Matz here:
"The basic naming for methods in standard class libraries are:
* use basic form (include not includes)
* put question mark for predicates
* put bang mark for "dangerous" version of methods
"is_a" and "has_key" are exceptions. "is_a" (or "isa") used very often
for inheritance in OO context.
"has_key" has already been deprecated by "key?"
"
I was wondering if this was really ment to ban has_ in predicate names.
In the example above I think it makes more sense to name the predicate #has_childen? instead of just #children?.
RSpecs language features underline my claim. When using has_ I can
write specs like this:
expect(father).to have_children
While without has_ this can only be written like this:
expect(father).to be_children
or
expect(father.children?).to eq true
A workaround is to name it #with_children? to spec it with
ok, the example was not well chosen. Let's have another one.
Human#has_father?
compared to
Human#father?
The first one would mean the obvious while the latter would mean "is a
father?" to most readers.
Kai
···
On Fri, Oct 23, 2015 at 10:18 AM, Doug Lake-Hammond <d.lakehammond@gmail.com> wrote:
Hi,
For me the reasoning is that has_ is redundant. What else could `children?`
mean?
Brevity is the soul of ruby
with_ will surprise others. If you don't agree with Rubocop I think it's
better to disable the rule in your .rubocop.yml.
I think 'expect(father.children?).to eq(true)' is ok, maybe not as
satisfying as have_children but still readable. Better to have good code
than good tests.
Regards,
Doug Hammond
On Fri, 23 Oct 2015 at 10:03 Kai Lehmann <kai@obfusco.de> wrote:
I was recently stumbling upon the Rubocop rule Style/PredicateName which
complained about predicate methods starting with has_ (e.g.
Human#has_children?).
Bozhidar Batsov (developer of Rubocop) explained that the rule was
based on a comment
made by Matz here:
"The basic naming for methods in standard class libraries are:
* use basic form (include not includes)
* put question mark for predicates
* put bang mark for "dangerous" version of methods
"is_a" and "has_key" are exceptions. "is_a" (or "isa") used very often
for inheritance in OO context.
"has_key" has already been deprecated by "key?"
"
I was wondering if this was really ment to ban has_ in predicate names.
In the example above I think it makes more sense to name the predicate #has_childen? instead of just #children?.
RSpecs language features underline my claim. When using has_ I can
write specs like this:
expect(father).to have_children
While without has_ this can only be written like this:
expect(father).to be_children
or
expect(father.children?).to eq true
A workaround is to name it #with_children? to spec it with
Hmmm, yes that's a better example. I would suggest `child?` instead of
`father?` but I can see this is still ambiguous (could be has_child or
is_child).
I think you are justified to turn off the rubocop rule for the file where
the API is defined. If you want to have predicates is_parent, has_parent,
is_child, has_child all together on one node it seems unavoidable. Anyone
else have suggestions?
Doug
···
On Fri, 23 Oct 2015 at 10:28 Kai Lehmann <kai@obfusco.de> wrote:
Hi again,
ok, the example was not well chosen. Let's have another one.
Human#has_father?
compared to
Human#father?
The first one would mean the obvious while the latter would mean "is a
father?" to most readers.
Kai
On Fri, Oct 23, 2015 at 10:18 AM, Doug Lake-Hammond > <d.lakehammond@gmail.com> wrote:
> Hi,
>
> For me the reasoning is that has_ is redundant. What else could
`children?`
> mean?
>
> Brevity is the soul of ruby
>
> with_ will surprise others. If you don't agree with Rubocop I think it's
> better to disable the rule in your .rubocop.yml.
>
> I think 'expect(father.children?).to eq(true)' is ok, maybe not as
> satisfying as have_children but still readable. Better to have good code
> than good tests.
>
> Regards,
> Doug Hammond
>
> On Fri, 23 Oct 2015 at 10:03 Kai Lehmann <kai@obfusco.de> wrote:
>>
>> I was recently stumbling upon the Rubocop rule Style/PredicateName which
>> complained about predicate methods starting with has_ (e.g.
>> Human#has_children?).
>>
>> Bozhidar Batsov (developer of Rubocop) explained that the rule was
>> based on a comment
>> made by Matz here:
>>
>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/43765
>>
>> "The basic naming for methods in standard class libraries are:
>>
>> * use basic form (include not includes)
>> * put question mark for predicates
>> * put bang mark for "dangerous" version of methods
>>
>> "is_a" and "has_key" are exceptions. "is_a" (or "isa") used very often
>> for inheritance in OO context.
>> "has_key" has already been deprecated by "key?"
>> "
>>
>> I was wondering if this was really ment to ban has_ in predicate names.
>>
>> In the example above I think it makes more sense to name the predicate
>> #has_childen? instead of just #children?.
>>
>> RSpecs language features underline my claim. When using has_ I can
>> write specs like this:
>>
>> expect(father).to have_children
>>
>> While without has_ this can only be written like this:
>>
>> expect(father).to be_children
>>
>> or
>>
>> expect(father.children?).to eq true
>>
>> A workaround is to name it #with_children? to spec it with
>>
>> expect(father).to be_with_children
>>
>> What do you think?
>>
>> Kai
Taken out of context, you make a valid point: "father?" is ambiguous.
Although even in this case, the message receiver is generally another
object, in which case it seems more natural that object.father? is asking
the object if it has a father. The question to ask the object to find out
if it is a father is, does it have any children? (object.children?)
In context though, it is not so ambiguous and shouldn't usually be a
problem.
Example:
if object.father?
child_count = object.children.count # feels a bit strange to me
end
···
On Fri, Oct 23, 2015 at 10:28 AM, Kai Lehmann <kai@obfusco.de> wrote:
Hi again,
ok, the example was not well chosen. Let's have another one.
Human#has_father?
compared to
Human#father?
The first one would mean the obvious while the latter would mean "is a
father?" to most readers.
Kai
On Fri, Oct 23, 2015 at 10:18 AM, Doug Lake-Hammond > <d.lakehammond@gmail.com> wrote:
> Hi,
>
> For me the reasoning is that has_ is redundant. What else could
`children?`
> mean?
>
> Brevity is the soul of ruby
>
> with_ will surprise others. If you don't agree with Rubocop I think it's
> better to disable the rule in your .rubocop.yml.
>
> I think 'expect(father.children?).to eq(true)' is ok, maybe not as
> satisfying as have_children but still readable. Better to have good code
> than good tests.
>
> Regards,
> Doug Hammond
>
> On Fri, 23 Oct 2015 at 10:03 Kai Lehmann <kai@obfusco.de> wrote:
>>
>> I was recently stumbling upon the Rubocop rule Style/PredicateName which
>> complained about predicate methods starting with has_ (e.g.
>> Human#has_children?).
>>
>> Bozhidar Batsov (developer of Rubocop) explained that the rule was
>> based on a comment
>> made by Matz here:
>>
>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/43765
>>
>> "The basic naming for methods in standard class libraries are:
>>
>> * use basic form (include not includes)
>> * put question mark for predicates
>> * put bang mark for "dangerous" version of methods
>>
>> "is_a" and "has_key" are exceptions. "is_a" (or "isa") used very often
>> for inheritance in OO context.
>> "has_key" has already been deprecated by "key?"
>> "
>>
>> I was wondering if this was really ment to ban has_ in predicate names.
>>
>> In the example above I think it makes more sense to name the predicate
>> #has_childen? instead of just #children?.
>>
>> RSpecs language features underline my claim. When using has_ I can
>> write specs like this:
>>
>> expect(father).to have_children
>>
>> While without has_ this can only be written like this:
>>
>> expect(father).to be_children
>>
>> or
>>
>> expect(father.children?).to eq true
>>
>> A workaround is to name it #with_children? to spec it with
>>
>> expect(father).to be_with_children
>>
>> What do you think?
>>
>> Kai
An object that asks itself if it's a father is an irresponsible parent:
"Who? Me, father again?" When would you want this behaviour? It seems like
that state that the object is going to have is where or not it has any
children:
def father?
self.children?
end
···
On Fri, Oct 23, 2015 at 10:51 AM, Doug Lake-Hammond <d.lakehammond@gmail.com > wrote:
Hmmm, yes that's a better example. I would suggest `child?` instead of
`father?` but I can see this is still ambiguous (could be has_child or
is_child).
I think you are justified to turn off the rubocop rule for the file where
the API is defined. If you want to have predicates is_parent, has_parent,
is_child, has_child all together on one node it seems unavoidable. Anyone
else have suggestions?
Doug
On Fri, 23 Oct 2015 at 10:28 Kai Lehmann <kai@obfusco.de> wrote:
Hi again,
ok, the example was not well chosen. Let's have another one.
Human#has_father?
compared to
Human#father?
The first one would mean the obvious while the latter would mean "is a
father?" to most readers.
Kai
On Fri, Oct 23, 2015 at 10:18 AM, Doug Lake-Hammond >> <d.lakehammond@gmail.com> wrote:
> Hi,
>
> For me the reasoning is that has_ is redundant. What else could
`children?`
> mean?
>
> Brevity is the soul of ruby
>
> with_ will surprise others. If you don't agree with Rubocop I think it's
> better to disable the rule in your .rubocop.yml.
>
> I think 'expect(father.children?).to eq(true)' is ok, maybe not as
> satisfying as have_children but still readable. Better to have good code
> than good tests.
>
> Regards,
> Doug Hammond
>
> On Fri, 23 Oct 2015 at 10:03 Kai Lehmann <kai@obfusco.de> wrote:
>>
>> I was recently stumbling upon the Rubocop rule Style/PredicateName
which
>> complained about predicate methods starting with has_ (e.g.
>> Human#has_children?).
>>
>> Bozhidar Batsov (developer of Rubocop) explained that the rule was
>> based on a comment
>> made by Matz here:
>>
>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/43765
>>
>> "The basic naming for methods in standard class libraries are:
>>
>> * use basic form (include not includes)
>> * put question mark for predicates
>> * put bang mark for "dangerous" version of methods
>>
>> "is_a" and "has_key" are exceptions. "is_a" (or "isa") used very often
>> for inheritance in OO context.
>> "has_key" has already been deprecated by "key?"
>> "
>>
>> I was wondering if this was really ment to ban has_ in predicate names.
>>
>> In the example above I think it makes more sense to name the predicate
>> #has_childen? instead of just #children?.
>>
>> RSpecs language features underline my claim. When using has_ I can
>> write specs like this:
>>
>> expect(father).to have_children
>>
>> While without has_ this can only be written like this:
>>
>> expect(father).to be_children
>>
>> or
>>
>> expect(father.children?).to eq true
>>
>> A workaround is to name it #with_children? to spec it with
>>
>> expect(father).to be_with_children
>>
>> What do you think?
>>
>> Kai
You make a good point, in the context of a receiver father? becomes less
ambiguous. To look at it another way, if you have an accessor `.father`
then it clearly refers to a different object, and so a complimentary
`father?` predicate is obviously `has_father?`
An API with 'children?', 'children', 'parent?' and 'parent' seems to cover
everything and could be understood quickly, no?
Doug
···
On Fri, 23 Oct 2015 at 10:59 Joe Gain <joe.gain@gmail.com> wrote:
You beat me to the answer button, Doug!
An object that asks itself if it's a father is an irresponsible parent:
"Who? Me, father again?" When would you want this behaviour? It seems like
that state that the object is going to have is where or not it has any
children:
def father?
self.children?
end
On Fri, Oct 23, 2015 at 10:51 AM, Doug Lake-Hammond < > d.lakehammond@gmail.com> wrote:
Hmmm, yes that's a better example. I would suggest `child?` instead of
`father?` but I can see this is still ambiguous (could be has_child or
is_child).
I think you are justified to turn off the rubocop rule for the file where
the API is defined. If you want to have predicates is_parent, has_parent,
is_child, has_child all together on one node it seems unavoidable. Anyone
else have suggestions?
Doug
On Fri, 23 Oct 2015 at 10:28 Kai Lehmann <kai@obfusco.de> wrote:
Hi again,
ok, the example was not well chosen. Let's have another one.
Human#has_father?
compared to
Human#father?
The first one would mean the obvious while the latter would mean "is a
father?" to most readers.
Kai
On Fri, Oct 23, 2015 at 10:18 AM, Doug Lake-Hammond >>> <d.lakehammond@gmail.com> wrote:
> Hi,
>
> For me the reasoning is that has_ is redundant. What else could
`children?`
> mean?
>
> Brevity is the soul of ruby
>
> with_ will surprise others. If you don't agree with Rubocop I think
it's
> better to disable the rule in your .rubocop.yml.
>
> I think 'expect(father.children?).to eq(true)' is ok, maybe not as
> satisfying as have_children but still readable. Better to have good
code
> than good tests.
>
> Regards,
> Doug Hammond
>
> On Fri, 23 Oct 2015 at 10:03 Kai Lehmann <kai@obfusco.de> wrote:
>>
>> I was recently stumbling upon the Rubocop rule Style/PredicateName
which
>> complained about predicate methods starting with has_ (e.g.
>> Human#has_children?).
>>
>> Bozhidar Batsov (developer of Rubocop) explained that the rule was
>> based on a comment
>> made by Matz here:
>>
>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/43765
>>
>> "The basic naming for methods in standard class libraries are:
>>
>> * use basic form (include not includes)
>> * put question mark for predicates
>> * put bang mark for "dangerous" version of methods
>>
>> "is_a" and "has_key" are exceptions. "is_a" (or "isa") used very often
>> for inheritance in OO context.
>> "has_key" has already been deprecated by "key?"
>> "
>>
>> I was wondering if this was really ment to ban has_ in predicate
names.
>>
>> In the example above I think it makes more sense to name the predicate
>> #has_childen? instead of just #children?.
>>
>> RSpecs language features underline my claim. When using has_ I can
>> write specs like this:
>>
>> expect(father).to have_children
>>
>> While without has_ this can only be written like this:
>>
>> expect(father).to be_children
>>
>> or
>>
>> expect(father.children?).to eq true
>>
>> A workaround is to name it #with_children? to spec it with
>>
>> expect(father).to be_with_children
>>
>> What do you think?
>>
>> Kai
пятница, 23 октября 2015 г. пользователь Doug Lake-Hammond написал:
I have nothing better to do
You make a good point, in the context of a receiver father? becomes less
ambiguous. To look at it another way, if you have an accessor `.father`
then it clearly refers to a different object, and so a complimentary
`father?` predicate is obviously `has_father?`
An API with 'children?', 'children', 'parent?' and 'parent' seems to cover
everything and could be understood quickly, no?
Doug
On Fri, 23 Oct 2015 at 10:59 Joe Gain <joe.gain@gmail.com > <javascript:_e(%7B%7D,'cvml','joe.gain@gmail.com');>> wrote:
You beat me to the answer button, Doug!
An object that asks itself if it's a father is an irresponsible parent:
"Who? Me, father again?" When would you want this behaviour? It seems like
that state that the object is going to have is where or not it has any
children:
def father?
self.children?
end
On Fri, Oct 23, 2015 at 10:51 AM, Doug Lake-Hammond < >> d.lakehammond@gmail.com >> <javascript:_e(%7B%7D,'cvml','d.lakehammond@gmail.com');>> wrote:
Hmmm, yes that's a better example. I would suggest `child?` instead of
`father?` but I can see this is still ambiguous (could be has_child or
is_child).
I think you are justified to turn off the rubocop rule for the file
where the API is defined. If you want to have predicates is_parent,
has_parent, is_child, has_child all together on one node it seems
unavoidable. Anyone else have suggestions?
Doug
On Fri, 23 Oct 2015 at 10:28 Kai Lehmann <kai@obfusco.de >>> <javascript:_e(%7B%7D,'cvml','kai@obfusco.de');>> wrote:
Hi again,
ok, the example was not well chosen. Let's have another one.
Human#has_father?
compared to
Human#father?
The first one would mean the obvious while the latter would mean "is a
father?" to most readers.
Kai
On Fri, Oct 23, 2015 at 10:18 AM, Doug Lake-Hammond >>>> <d.lakehammond@gmail.com >>>> <javascript:_e(%7B%7D,'cvml','d.lakehammond@gmail.com');>> wrote:
> Hi,
>
> For me the reasoning is that has_ is redundant. What else could
`children?`
> mean?
>
> Brevity is the soul of ruby
>
> with_ will surprise others. If you don't agree with Rubocop I think
it's
> better to disable the rule in your .rubocop.yml.
>
> I think 'expect(father.children?).to eq(true)' is ok, maybe not as
> satisfying as have_children but still readable. Better to have good
code
> than good tests.
>
> Regards,
> Doug Hammond
>
> On Fri, 23 Oct 2015 at 10:03 Kai Lehmann <kai@obfusco.de >>>> <javascript:_e(%7B%7D,'cvml','kai@obfusco.de');>> wrote:
>>
>> I was recently stumbling upon the Rubocop rule Style/PredicateName
which
>> complained about predicate methods starting with has_ (e.g.
>> Human#has_children?).
>>
>> Bozhidar Batsov (developer of Rubocop) explained that the rule was
>> based on a comment
>> made by Matz here:
>>
>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/43765
>>
>> "The basic naming for methods in standard class libraries are:
>>
>> * use basic form (include not includes)
>> * put question mark for predicates
>> * put bang mark for "dangerous" version of methods
>>
>> "is_a" and "has_key" are exceptions. "is_a" (or "isa") used very
often
>> for inheritance in OO context.
>> "has_key" has already been deprecated by "key?"
>> "
>>
>> I was wondering if this was really ment to ban has_ in predicate
names.
>>
>> In the example above I think it makes more sense to name the
predicate
>> #has_childen? instead of just #children?.
>>
>> RSpecs language features underline my claim. When using has_ I can
>> write specs like this:
>>
>> expect(father).to have_children
>>
>> While without has_ this can only be written like this:
>>
>> expect(father).to be_children
>>
>> or
>>
>> expect(father.children?).to eq true
>>
>> A workaround is to name it #with_children? to spec it with
>>
>> expect(father).to be_with_children
>>
>> What do you think?
>>
>> Kai
пятница, 23 октября 2015 г. пользователь Doug Lake-Hammond написал:
I have nothing better to do
You make a good point, in the context of a receiver father? becomes less
ambiguous. To look at it another way, if you have an accessor `.father`
then it clearly refers to a different object, and so a complimentary
`father?` predicate is obviously `has_father?`
An API with 'children?', 'children', 'parent?' and 'parent' seems to
cover everything and could be understood quickly, no?
Doug
On Fri, 23 Oct 2015 at 10:59 Joe Gain <joe.gain@gmail.com> wrote:
You beat me to the answer button, Doug!
An object that asks itself if it's a father is an irresponsible parent:
"Who? Me, father again?" When would you want this behaviour? It seems like
that state that the object is going to have is where or not it has any
children:
def father?
self.children?
end
On Fri, Oct 23, 2015 at 10:51 AM, Doug Lake-Hammond < >>> d.lakehammond@gmail.com> wrote:
Hmmm, yes that's a better example. I would suggest `child?` instead of
`father?` but I can see this is still ambiguous (could be has_child or
is_child).
I think you are justified to turn off the rubocop rule for the file
where the API is defined. If you want to have predicates is_parent,
has_parent, is_child, has_child all together on one node it seems
unavoidable. Anyone else have suggestions?
Doug
On Fri, 23 Oct 2015 at 10:28 Kai Lehmann <kai@obfusco.de> wrote:
Hi again,
ok, the example was not well chosen. Let's have another one.
Human#has_father?
compared to
Human#father?
The first one would mean the obvious while the latter would mean "is a
father?" to most readers.
Kai
On Fri, Oct 23, 2015 at 10:18 AM, Doug Lake-Hammond >>>>> <d.lakehammond@gmail.com> wrote:
> Hi,
>
> For me the reasoning is that has_ is redundant. What else could
`children?`
> mean?
>
> Brevity is the soul of ruby
>
> with_ will surprise others. If you don't agree with Rubocop I think
it's
> better to disable the rule in your .rubocop.yml.
>
> I think 'expect(father.children?).to eq(true)' is ok, maybe not as
> satisfying as have_children but still readable. Better to have good
code
> than good tests.
>
> Regards,
> Doug Hammond
>
> On Fri, 23 Oct 2015 at 10:03 Kai Lehmann <kai@obfusco.de> wrote:
>>
>> I was recently stumbling upon the Rubocop rule Style/PredicateName
which
>> complained about predicate methods starting with has_ (e.g.
>> Human#has_children?).
>>
>> Bozhidar Batsov (developer of Rubocop) explained that the rule was
>> based on a comment
>> made by Matz here:
>>
>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/43765
>>
>> "The basic naming for methods in standard class libraries are:
>>
>> * use basic form (include not includes)
>> * put question mark for predicates
>> * put bang mark for "dangerous" version of methods
>>
>> "is_a" and "has_key" are exceptions. "is_a" (or "isa") used very
often
>> for inheritance in OO context.
>> "has_key" has already been deprecated by "key?"
>> "
>>
>> I was wondering if this was really ment to ban has_ in predicate
names.
>>
>> In the example above I think it makes more sense to name the
predicate
>> #has_childen? instead of just #children?.
>>
>> RSpecs language features underline my claim. When using has_ I can
>> write specs like this:
>>
>> expect(father).to have_children
>>
>> While without has_ this can only be written like this:
>>
>> expect(father).to be_children
>>
>> or
>>
>> expect(father.children?).to eq true
>>
>> A workaround is to name it #with_children? to spec it with
>>
>> expect(father).to be_with_children
>>
>> What do you think?
>>
>> Kai
пятница, 23 октября 2015 г. пользователь Doug Lake-Hammond написал:
I have nothing better to do
You make a good point, in the context of a receiver father? becomes less ambiguous. To look at it another way, if you have an accessor `.father` then it clearly refers to a different object, and so a complimentary `father?` predicate is obviously `has_father?`
An API with 'children?', 'children', 'parent?' and 'parent' seems to cover everything and could be understood quickly, no?
Doug
On Fri, 23 Oct 2015 at 10:59 Joe Gain < joe.gain@gmail.com > wrote:
You beat me to the answer button, Doug!
An object that asks itself if it's a father is an irresponsible parent: "Who? Me, father again?" When would you want this behaviour? It seems like that state that the object is going to have is where or not it has any children:
def father?
self.children?
end
On Fri, Oct 23, 2015 at 10:51 AM, Doug Lake-Hammond < d.lakehammond@gmail.com > wrote:
Hmmm, yes that's a better example. I would suggest `child?` instead of `father?` but I can see this is still ambiguous (could be has_child or is_child).
I think you are justified to turn off the rubocop rule for the file where the API is defined. If you want to have predicates is_parent, has_parent, is_child, has_child all together on one node it seems unavoidable. Anyone else have suggestions?
Doug
On Fri, 23 Oct 2015 at 10:28 Kai Lehmann < kai@obfusco.de > wrote:
Hi again,
ok, the example was not well chosen. Let's have another one.
Human#has_father?
compared to
Human#father?
The first one would mean the obvious while the latter would mean "is a
father?" to most readers.
Kai
On Fri, Oct 23, 2015 at 10:18 AM, Doug Lake-Hammond >>>>>>< d.lakehammond@gmail.com > wrote:
Hi,
For me the reasoning is that has_ is redundant. What else could `children?`
mean?
Brevity is the soul of ruby
with_ will surprise others. If you don't agree with Rubocop I think it's
better to disable the rule in your .rubocop.yml.
I think 'expect(father.children?).to eq(true)' is ok, maybe not as
satisfying as have_children but still readable. Better to have good code
than good tests.
Regards,
Doug Hammond
On Fri, 23 Oct 2015 at 10:03 Kai Lehmann < kai@obfusco.de > wrote:
I was recently stumbling upon the Rubocop rule Style/PredicateName which
complained about predicate methods starting with has_ (e.g.
Human#has_children?).
Bozhidar Batsov (developer of Rubocop) explained that the rule was
based on a comment
made by Matz here:
"The basic naming for methods in standard class libraries are:
* use basic form (include not includes)
* put question mark for predicates
* put bang mark for "dangerous" version of methods
"is_a" and "has_key" are exceptions. "is_a" (or "isa") used very often
for inheritance in OO context.
"has_key" has already been deprecated by "key?"
"
I was wondering if this was really ment to ban has_ in predicate names.
In the example above I think it makes more sense to name the predicate #has_childen? instead of just #children?.
RSpecs language features underline my claim. When using has_ I can
write specs like this:
expect(father).to have_children
While without has_ this can only be written like this:
expect(father).to be_children
or
expect(father.children?).to eq true
A workaround is to name it #with_children? to spec it with
