Lint on unnecessary {} in string interpolation (Style Guide - Proposed)

[pq]

Migrated from dartbug.com/22025:

If the interpolated expression is just a simple identifier (and the string after the interpolation is not alphanumeric), then the {} are not needed. Given:

"Hi, ${name}!"

The linter should suggest:

"Hi, $name!"

[zoechi]

I wouldn't want this. IMHO the curly braces improve the visibility that the string contains an interpolated part.

[pq]

@zoechi: I'm on the fence about this one myself.

@munificent is the reporter... Perhaps Bob cares to elaborate on the rationale?

[munificent]

I see a decent amount of Dart code that uses "...${name}..." instead of "...$name..." I think because users are coming from other string interpolation languages that always require delimiters.

Not needing them in Dart is a nice feature that makes the strings shorter and less jumbled up with punctuation. A linter can help make sure users know this is even an option.

I don't find code harder to read when it leaves off the curlies—all of my IDEs and text editors will highlight interpolation in a different color anyway, which is more helpful than some extra punctuation.

[seaneagan]

I definitely do remove ${foo} whenever I see it. To me, when I see ${} it means I need to scan for whatever complex expression may be inside it, so in that way it is less readable to me. I often create local variables with meaningful names just to avoid ${}. IMO when using an editor with syntax highlighting the visibility of $foo is good, so that's not a concern for me, but probably more so for anyone using a plain text editor.

[zoechi]

I usually also don't have complex expressions but I often change between values which need a prefix and which don't, during development (just use the toString() output or explicitly choose a field like 'xxx ${person.lastName}' yyy vs 'xxx ${person}' yyy and I wouldn't want to add/remove the curly braces every time.
I just stick to the form with the braces and I guess because I am accustomed to this form I find it harder to parse when it's missing.

I don't care how others do it but I wouldn't want an analyzer or linter bothering me about this.

[munificent]

I wouldn't want to add/remove the curly braces every time.

Hopefully, the linter will be able to do this for you eventually. :)

[zoechi]

Removing would probably be easy, but adding?
I hope the linter will allow to configure what it should complain about.

[seaneagan]

@zoechi See #57153 for configurability, but I think we should wait and see how much consensus we can come to before adding that complexity.

[pq]

Great conversation! A few thoughts.

1. Absolutely the linter will be configurable. No details yet (we need to walk before we can run) but certainly there will be the need for user defined rulesets (if only so @zoechi can disable this one ;)). Ideas on this front absolutely welcome over on Linter Configurability #57153 .
2. Quick fixes are absolutely on the horizon. TBH they won't be hard at all to implement assuming we piggyback on the analysis server's fix/assist support (which I think we should).

Incidentally, I took a quick crack at implementing this rule and wrote a corresponding test. I did this mainly to prove out that I could get things running from end to end. Anyway, comments and additional test cases are most welcome.

• Rule: https://github.com/dart-lang/dart_lint/blob/master/lib/src/rules/unnecessary_brace_in_string_interp.dart
• Test: https://github.com/dart-lang/dart_lint/blob/master/test/rules/unnecessary_brace_in_string_interp.dart

[pq]

Fixed as of e7c35b3