Before You File a Proposal Please Confirm You Have Done The Following...

• I havesearched for related issues and found none that match my proposal.
• I have searched thecurrent rule list and found no rules that match my proposal.
• I haveread the FAQ and my problem is not listed.

My proposal is suitable for this project

• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Link to the rule's documentation

https://typescript-eslint.io/play/#ts=5.0.4&sourceType=module&code=CYUwxgNghgTiAEYD2A7AzgF3gNyhAriAFzyYwCWKA5gNwBQd5AZvABS4EgDaADALrwAvMJx5CvPgDoMSAKoAHeSBgBhKGhCsAlFvgBvOvHgB6Y-EkW6AXwbM2HQpMywMaAOrkMAC3Zju-aTlFZTUNbR19QxMzC0lrOiA&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQAIBcBPABxQGNoBLY-AWhXkoDt8B6Y6RAM0WluXxUmAc374AhtHzJ6TACYyA7pXwALdFF7QA9tEjgwAXxCGgA

Description

Coming over from#7138 (comment): when checking whether a string's[0] member equals a modification of[0], the rule's preference ends up being even more code:

declareconstvalue:string;if(value[0]===value[0].toUpperCase()){/* ... */}// beforeif(value.startsWith(value[0].toUpperCase())){/* ... */}// after

Agreeing with@bradzacher:

I actually think that the previous form is clearer for this specific case.
It's also substantially faster (not that it matters at the this speed... but it is twice as fast - ~1.2B ops/s vs ~2.4B ops/s).

I wonder if we should add an option to skip this case from the rule?

It's not yet clear to me how we would categorize and describe "this case". Maybe it's that we don't want to flag cases that are just checking whethervalue[0] === something? In that case, maybe the option would be named something likecheckFirstElementEquality?

Fail

n/a

Pass

n/a

Additional Info

No response