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

Created on 4 Feb 2015  路  13Comments  路  Source: dart-lang/linter

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!"

enhancement

Most helpful comment

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

All 13 comments

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

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

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

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鈥攁ll of my IDEs and text editors will highlight interpolation in a different color anyway, which is more helpful than some extra punctuation.

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.

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.

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

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

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

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

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 #7 .
  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.

Fixed as of e7c35b3b75334d28c59c20fb4dd63f2bcb8aac33

Is there any way to remove this lint warning permanently in Android Studio?

@dark-chocolate lints need to be enabled explicitly in analysis_options.yaml

Thanks @zoechi , it worked.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

pq picture pq  路  5Comments

JulianBissekkou picture JulianBissekkou  路  4Comments

pq picture pq  路  4Comments

goderbauer picture goderbauer  路  3Comments

jelenalecic picture jelenalecic  路  3Comments