Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
pq opened this issue Feb 4, 2015 · 13 comments
Closed

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

pq opened this issue Feb 4, 2015 · 13 comments
Assignees
Labels
analyzer-linter Issues with the analyzer's support for the linter package area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. type-enhancement A request for a change that isn't a bug

Comments

@pq
Copy link
Member

pq commented Feb 4, 2015

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

@pq pq added the type-enhancement A request for a change that isn't a bug label Feb 4, 2015
@zoechi
Copy link
Contributor

zoechi commented Feb 4, 2015

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

@pq
Copy link
Member Author

pq commented Feb 4, 2015

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

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

@munificent
Copy link
Member

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
Copy link

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.

@pq pq self-assigned this Feb 5, 2015
@zoechi
Copy link
Contributor

zoechi commented Feb 5, 2015

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
Copy link
Member

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
Copy link
Contributor

zoechi commented Feb 5, 2015

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

@seaneagan
Copy link

@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
Copy link
Member Author

pq commented Feb 5, 2015

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.

@pq pq changed the title Lint on unnecessary {} in string interpolation Lint on unnecessary {} in string interpolation (Style Guide) Feb 6, 2015
@pq
Copy link
Member Author

pq commented Feb 6, 2015

Fixed as of e7c35b3

@pq pq changed the title Lint on unnecessary {} in string interpolation (Style Guide) Lint on unnecessary {} in string interpolation (Style Guide - Proposed) Feb 7, 2015
@dark-chocolate
Copy link

dark-chocolate commented Sep 10, 2018

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

@zoechi
Copy link
Contributor

zoechi commented Sep 10, 2018

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

@dark-chocolate
Copy link

dark-chocolate commented Sep 10, 2018

Thanks @zoechi , it worked.

@devoncarew devoncarew added analyzer-linter Issues with the analyzer's support for the linter package area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. labels Nov 18, 2024
@devoncarew devoncarew transferred this issue from dart-lang/linter Nov 18, 2024
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
analyzer-linter Issues with the analyzer's support for the linter package area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

6 participants