add rule to encourage checking isEmpty over comparing count to zero

[jpsim]

This already helped catch some inefficient calls in SwiftLint 🎉, but I don't think we can merge this as is currently implemented.

I can picture two false positives happening in practice with the way this rule is currently implemented:

1. Int variable named count. In this case, it'd be fine to check count against zero.
2. Calling count on types that don't incur a performance hit e.g. struct A { let count: Int }.

I'd appreciate any ideas to help address these two false positives.

[segiddins]

Checking if the type is a collection?

[jpsim]

Checking if the type is a collection?

How?

[segiddins]

Don't you have the type of the item from the sourcekit request?

[jpsim]

Don't you have the type of the item from the sourcekit request?

Not quite. You can get that if you have all the required compiler arguments for the given Swift file, which jazzy has but SwiftLint doesn't currently use. To get those, the project has to be fully compiled & indexed and we need to run xcodebuild -dry-run to get the arguments. This is already sub-optimal for jazzy, but completely unacceptable for SwiftLint.

[segiddins]

Ah gotcha, I thought SwiftLint operated on the same source transformation

[jpsim]

I've revived this now that we have opt-in rules. I'm making this an opt-in rule because it can easily lead to false positives as mentioned in the first comment in this PR. However, this is still tremendously useful as I constantly find myself comparing count against zero.

[BluMist]

also, with regard to the rule itself...

if I have an optional array,
if array?.count > 0
might be easier to read than
if array?.isEmpty != true
to account for the nil and false scenario

[jpsim]

This rule isn't so much about style as it is performance. Many data structures allow for more efficient checking if it's empty or not (O(1)) than counting all of the elements (O(n)).