Suggestions: Iterators

[Veedrac]

.filter().next() → .find()
.find().is_some() → .any()

These seem to catch people out rather frequently. It catches me out because it's what you do in Python. This also technically includes:

.position().is_some() → .any()
.rposition().is_some() → .any()

Perhaps also the similar Python idiom

left.zip(right).all(|(a, b)| a == b) → left.eq(right)

although that's contingent on length equality.

There's also the question of whether filter_map is better than flat_map when returning Option<T>. They're kind'a the same thing, but maybe one is better than the other. Maybe not though.

[llogiq]

The eq one is tricky, because folks may implement it however they see fit. Apart from that, good idea!

[devonhollowood]

I can do this if you want--I think this will just involve adding some code to the MethodsPass in src/methods.rs. Would you want this to be one lint or multiple?

While I'm at it, how would you feel about refactoring some of the code in MethodsPass's check_expr()? I think that moving the lint checks to their own methods would make the code a bit easier to read here, especially because it wouldn't get quite so indented. It also might be nice to add a function which would check for chained method calls by name, since that seems to be a common theme here.

[Manishearth]

Methods.rs sounds good. Multiple, probably, but your choice.

👍 to the proposed refactorings too

[devonhollowood]

Made a pull request for the proposed refactor (I thought it would be cleaner to submit a pull request for the refactor, and then to add the new lints separately).

[Manishearth]

Great! Feel free to add the new lint to that PR as a separate commit; that works too.

[Manishearth]

fixed in #524

[llogiq]

Shall we close this or are we missing anything?

[Manishearth]

I just clicked the wrong button