prefer_first & prefer_last

[NatoBoram]

Describe the rule you'd like to see implemented

Include as much detail as you can.

Using users.first instead of users[0] isn't exactly that important, but it might be something that a team wants to enforce in order to be more consistent or adhering more to a "pick one and stick to it" philosophy.

I think this rule is the next logical step after prefer_is_empty and prefer_is_not_empty.

This should include a description of who would use the lint (such as if it's
specific to a framework like Flutter), what conditions the rule should look
for, and what conditions the rule should ignore.

Such a rule should catch users[0] as well as users[users.length - 1]

Examples

Ideally, provide motivating examples w/ rationale.

Additional context

Add any other considerations or context here.

[pq]

📟 @munificent ?

[incendial]

If anyone is willing to try a custom analyzer plugin called Dart Code Metrics, we have prefer-first and prefer-last rules implemented among with other useful lint rules.

[munificent]

Preferring isEmpty and isNotEmpty is important largely because length can be much slower to compute and is pointless when all you need to know is whether the length is non-zero. I don't know of any commonly used implementations of Iterable that have optimized first or last getters, though there could be.

Given that, Effective Dart is silent on using first and last versus []. Personally, I think it's good to be agnostic because sometimes the surrounding code leans towards one or the other. I wouldn't want users to have to use .first if adjacent code did [1], or something. So I prefer having Effective Dart say nothing and I don't think we'd want a linter rule for it to be in the recommended set.

I'm agnostic as to whether there's a linter rule that other users can opt into.

[pq]

Thanks @munificent!

This one feels situational enough that I'm guessing folks wouldn't want it enforced absolutely. That said, often times I think first and last are overlooked because folks aren't aware that they exist. To help with that lints like this can come in handy run occasionally to kind of harvest opportunities to improve readability. (I feel similarly about #58304 -- which I think might be useful to run occasionally to make sure unintended !s haven't snuck in, or been left behind by automated migrations.)

I've often thought it'd be useful to think about this class of lints a bit differently but haven't gotten any further than the feeling that there's something there.... Needless to say, any input is welcome!

[NatoBoram]

Many lints aren't there for performance reasons, but for style, consistency and maintainability. If there's a row of ..[0]..[1]..[2], there's probably something wrong with the code anyway.

I wouldn't put it in the recommended section either, but it's a good opt-in. As for effective Dart, one could say it's loosely related to prefer a noun phrase.

[matanlurey]

Just to offer a different perspective on this, there are plenty of lints that push developers to do things the team itself (or Bob) would or would not do. Personally I think names.first reads much better than names[0], and especially think names.last reads much better than names[names.length - 1].

I wouldn't force others to rewrite their code base, but it seems like a nice optional lint (ideally with a quick fix).

[mateusfccp]

I am someone who always used list.first and list.last instead of list[0] and list[list.length - 1]. This changed when I discovered that the implementation for list.first and list.last are not optimized. list.first is not that bad, as although it uses the iterator, it will return in the [sic] first item, but having to iterate though all items to get item.last is a real no-no for me.

Not arguing that the lint should not be implemented, but maybe we should also work in direction of having optimized implementations of first and last, so more people may use this lint without worrying about performance.

[NatoBoram]

Sounds like an easy fix, you could even make a PR for this.

That said, that's a separate issue from this one and we can resolve both of them asynchronously