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

New lint: avoid_compile_constants #58165

Closed
tomlenehan-google opened this issue May 12, 2020 · 5 comments · Fixed by dart-lang/linter#2100
Closed

New lint: avoid_compile_constants #58165

tomlenehan-google opened this issue May 12, 2020 · 5 comments · Fixed by dart-lang/linter#2100
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. linter-lint-request type-enhancement A request for a change that isn't a bug

Comments

@tomlenehan-google
Copy link

Avoid using compile time constants

The lint would trigger upon the use of the three Flutter fromEnvironment constructors:
int.fromEnvironment
string.fromEnvironment
bool.fromEnvironment

bool.hasEnvironment should also trigger the lint.

Using a compile constant creates a hidden global state in the program, with no defined method to determine the state or understand its use when reading the code (unlike flags a compile time constant might only be referenced during the fromEnvironment constructor call). If used heavily it makes the program hard to understand.

@tomlenehan-google tomlenehan-google added type-enhancement A request for a change that isn't a bug linter-lint-request labels May 12, 2020
@pq
Copy link
Member

pq commented May 18, 2020

LGTM. I think we should tweak the name (favoring do_not_use over avoid) and being explicit about the APIs we're restricting.

After chatting w/ @bwilkerson, I'm in favor of:

do_not_use_fromEnvironment.

@pq pq self-assigned this May 18, 2020
@pq
Copy link
Member

pq commented May 18, 2020

Hmm, actually, since hasEnvironment is in there too, it might be better to say do_not_use_environment.

@bwilkerson
Copy link
Member

Agreed.

@rakudrama
Copy link
Member

I have to say I don't really understand the motivation. The environment is baked into the app by the compiler. You can't do anything in the app to change the result, so it is more lake a configuration rather than (mutable) state.

One big advantage of, e.g. const bool.fromEnvironment is that since it is baked into the app by the compiler, the app can be optimized against the configuration, for example, tree-shaking all the dependent code.

This is not true of an alternative like a command-line option, which must not be optimized away in case the app is passed a command line with the option. Avoiding the 'environment' will always result in larger compiled apps.

@pq
Copy link
Member

pq commented May 19, 2020

The environment is baked into the app by the compiler.

👍

I think this is for the case where you specifically don't want that.

Maybe @tomlenehan-google can better motivate and I can update the docs to capture when this might be most appropriate?

Thanks for the feedback!

@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
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. linter-lint-request type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants