Skip to content

Refactoring operations should use var/final/const as appropriate #50018

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

Open
Tracked by #55825
stevemessick opened this issue Sep 20, 2022 · 2 comments
Open
Tracked by #55825

Refactoring operations should use var/final/const as appropriate #50018

stevemessick opened this issue Sep 20, 2022 · 2 comments
Labels
area-devexp For issues related to the analysis server, IDE support, linter, `dart fix`, and diagnostic messages. devexp-refactoring Issues with analysis server refactorings devexp-ux P3 A lower priority bug or feature request type-enhancement A request for a change that isn't a bug

Comments

@stevemessick
Copy link
Contributor

Original issue: flutter/flutter-intellij#6304

Summary: refactoring operations that create new declarations should use final and const where appropriate. Currently, var is used everywhere.

@stevemessick stevemessick added the legacy-area-analyzer Use area-devexp instead. label Sep 20, 2022
@bwilkerson
Copy link
Member

It seems like the Dart analyzer ought to be able to determine that a declaration should be var if its redefined, final it is isn't, and const if it is a constant (not sure about that last).

I wish it were that simple. The problem, of course, is that the variable didn't exist before the extract operation, so it's guaranteed that it isn't re-assigned yet. What we can't know is whether the user will assign a new value after this operation.

The point about const is interesting. If the original expression is a const expression, then perhaps we should use const for it. (It isn't guaranteed that that's the right thing either, but it is an interesting signal.)

That said, the original point is valid and something we have been discussing. The question is, what signals can we use to determine the user's preferences? One signal that comes to mind is style-based lints that have been enabled. In this case, it seems clear that if the user has enabled prefer_final_locals then they probably want the variable to be declared using final. The question is whether that's sufficient.

@srawlins srawlins added P3 A lower priority bug or feature request devexp-ux devexp-refactoring Issues with analysis server refactorings labels Sep 20, 2022
@asashour
Copy link
Contributor

Duplicate of #49561, but this has feedback.

@srawlins srawlins added the type-enhancement A request for a change that isn't a bug label Mar 14, 2024
@bwilkerson bwilkerson added area-devexp For issues related to the analysis server, IDE support, linter, `dart fix`, and diagnostic messages. and removed legacy-area-analyzer Use area-devexp instead. labels Feb 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-devexp For issues related to the analysis server, IDE support, linter, `dart fix`, and diagnostic messages. devexp-refactoring Issues with analysis server refactorings devexp-ux P3 A lower priority bug or feature request type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

4 participants