Add use_string_buffers to the core or recommended sets

[Levi-Lesches]

Using string buffers instead of += can save a lot of time and space, as seen in this issue: dart-lang/sdk#50304. StringBuffer isn't necessarily ubiquitous, so the lint that tells you to use it should be enabled by default, either in core or recommended.

[natebosch]

I worry a bit about recommending this one. The false positives may be rare, but I like to avoid lints with legitimate false positives that don't have any other mechanism than an // ignore. dart-lang/sdk#57777

I know @kevmoo is a fan of this lint. It does help more often than it hurts.

[kevmoo]

It keeps folks from using myString = myString + 'more stuff'; – which has HORRIBLE performance implications in Dart (I forgot who recently talked about how V8 has special hacks for this – @mraleph ?)

[kevmoo]

Ha! It was the referenced issue. 🤦

[kevmoo]

Short version: yes, I'm a fan.

I think // ignore is fine for one-offs. it forces folks to document why they avoid the best practice IMHO

[lrhn]

It keeps folks from using myString = myString + 'more stuff'; – which has HORRIBLE performance implications in Dart

It's only a problem if you do it inside a loop, or do it repeatedly with long strings. Otherwise the overhead of allocating a StringBuffer with an internal growable list (two more objects) and six other fields, can very quickly cost more than just copying the bytes of myString once or twice.

The lint description is (as usual) very terse and doesn't say where it applies. If it applies outside of loops, and not just for more than n repeated additions to the same string in linear code, then it's simply too strict. Using String.operator+ is OK in some cases.

[devoncarew]

After discussion, we think this lint will have too many false positives to add to package:lints. We would want this to only trigger for performance sensitive sections of code, but its not clear how we could successfully lint for that.