linter

linter copied to clipboard

Update:

as communicated below:

Would it make sense to expand it to covering additional cases where a non-String will automatically be converted, such as in string interpolations ('aaa ${x.toString()} zzz') and asserts, or in SDK APIs that take any object and convert it to a string using toString, such as StringBuffer.write.

~~## unnecessary_toString~~

~~## Description~~

~~Avoid calling toString on strings.~~

~~## Details~~

~~Avoid calling toString on strings. The target is already a String.~~

~~## Kind~~

~~Unneeded code.~~

~~## Good Examples ~~

~~String s1 = '';~~ ~~String s2 = s1;~~

~~## Bad Examples~~

~~String s1 = '';~~ ~~String s2 = s1.toString();~~

~~## Discussion~~

~~avoid_type_to_string is related.~~

How often does this occur in real code?

Would it make sense to expand it to covering additional cases where a non-String will automatically be converted, such as in string interpolations ('aaa ${x.toString()} zzz') and asserts, or in SDK APIs that take any object and convert it to a string using toString, such as StringBuffer.write.

noop_primitive_operations might fit this bill already?

noop_primitive_operations might fit this bill already?

Indeed, this is it.

... to expand it to covering additional cases ..

I guess yes, why not. The more value added to the user, the better.

'aaa ${x.toString()} zzz' is already covered. Not sure about the rest.

Sounds like the next step is to determine a list of cases that noop_primitive_operations doesn't currently cover that might be appropriate to add to it, then decide for each such case whether or not we want to support it (taking into consideration the impact of users that have already enabled that lint).

/fyi @a14n

As #3379 has been merged can we close this issue?