Add collection querying rule

[lovro-bikic]

Adds a rule to complement RuboCop PR rubocop/rubocop#14288.

This rule suggests to use Enumerable querying methods rather than expressions with #count to check if collections meet some criteria.

[pirj]

Those two methods are not mutually interchangeable in the general case, are they?
The cop is marked as unsafe.
The two methods differ semantically.
Do we need a guideline to prefer one over the next other?

How important is it to have this guideline to get the referenced cop merged?

[lovro-bikic]

Good questions! I'll answer what I can from my side.

Those two methods are not mutually interchangeable in the general case, are they?

It depends on method signature.

With a block, they're mutually interchangeable (e.g. x.count(&:something).positive? == x.any?(&:something)) if you only care about the return value (as long as #something doesn't run side effects).

With no arguments, they're mutually interchangeable as long as the collection doesn't include falsy values (this has been noted in the rule).

The two methods differ semantically.

This can be discussed, but assuming users work with truthy-value collections, I believe the semantics are the same, but predicates express them more clearly.

For example, in this Rails report, the cop commonly caught stuff like Article.where(published: true).count == 0 (check if there are no published articles), the intention which I think Article.where(published: true).none? makes more obvious and human readable.

The cop is marked as unsafe.

I'm not sure what should this comment signify, but there's a fair number of unsafe cops that are linked to style guide rules.

[pirj]

With a block, they're mutually interchangeable

Fair enough. However, we can’t guide those who have falsey values in enumerbles if they’re not passing a block.

if you only care about the return value (as long as #something doesn't run side effects).

Interesting mention. any? would return early without calling the block on all entries, while count will.

For example, rubocop/rubocop#14288 (comment), the cop commonly caught stuff like Article.where(published: true).count == 0 (check if there are no published articles), the intention which I think Article.where(published: true).none? makes more obvious and human readable

True that. But that’s AR-specific. There’s also performance to consider rubocop/rails-style-guide#232 (comment)

but there's a fair number of unsafe cops that are linked to style guide rules.

I would guess because cop can’t reliably detect the type, eg Array vs AR::Relation.
But in our case the cop is unsafe, but there’s some unsafety to the guideline itself, too, specifically the non-block form with enumerables having falsey values.

What do you think of reducing the scope of the guideline to only tell about the block form of count?

My primary concern here is that those guidelines aim to prevent programmers from making mistakes, while using any? instead of count may work, but is a time bomb, which will blow up when falsey values start appearing in the data.

[bbatsov]

The guidelines are not laws, but rather suggestions for the most common cases that people might encounter. While there are caveats to be kept in mind, I do think that in most cases using the querying methods is the way to go and most likely people don't use them just because they forget about them (or are not aware of them in the first place).

[bbatsov]

You might also want to add a bit of rationale here (e.g. readability and better performance in some cases)

[lovro-bikic]

Added a paragraph that explains readability and performance benefits

[bbatsov]

Btw, there's also length to consider. ;-)

[lovro-bikic]

Yep, updated. Note just that I wouldn't include length/size in the cop because it would yield too many false positives since Ruby has core classes which implement those methods, but aren't Enumerable (e.g. Integer, String, etc.).

[bbatsov]

Yeah, I figured as much although probably this should be also mentioned in the cop's docs as well, and we can also provide "conservative/aggressive" modes there in case someone wants to do a broader search in their codebase (e.g. on a one off basis). Anyways, that's not relevant to the PR here.

[bbatsov]

One more thing - this should probably mention length as well. (https://batsov.com/articles/2014/02/17/the-elements-of-style-in-ruby-number-13-length-vs-size-vs-count/)

In general for me the use of count without a block is a code smell on its own.

[pirj]

Can we exclude this?
Would it be possible to write a separate guideline for this?
If we harvest real-world-ruby-apps repos, what usages of count will there be?

[bbatsov]

Why do you think this should be separated?

For methods like count you should also keep in mind that it's a different method in Enumerable and ActiveRelation and it will probably be hard for us to tell them apart with a simple search.

[pirj]

Indeed, but if it’s not a list of repos of Rails apps like real-world-ruby-apps, chances are higher that it’s an Enumerable.

[pirj]

Using any? instead of count may work, but is a time bomb, which will blow up when falsey values start appearing in the data.

[bbatsov]

I think we just need a couple of examples illustrating the behavior with such values, perhaps in a sidebar/callout.

[lovro-bikic]

If we harvest real-world-ruby-apps repos, what usages of count will there be?

@pirj I've attached a report for real-world-ruby-apps here: rubocop/rubocop#14288 (comment)