Skip to content

proposal: avoid_var_declarations #58608

Closed
@minhqdao

Description

@minhqdao

avoid_var_declarations

Description

Avoid using var altogether. Instead, declare a variable using its explicit type, final or const.

Details

Declaring a variable using its explicit type is slightly more verbose but improves readability, adds self-documentation (also in terms of whether the variable is nullable or not) and makes sure that you are not dependant on compiler-inferred types. Declaring variables as final is good practice because it helps avoiding accidental reassignments and allows the compiler to do optimization.

Kind

Style.

Good Examples

class Person {
  String name = 'Bella';
  int age = 64;
  static const ageAtBirth = 0;

  void celebratesBirthday() => age++;
  void addsSecondName(String secondName) => name = '$name $secondName';
}

Bad Examples

class Person {
  var name = 'Bella';
  var age = 64;
  var ageAtBirth = 0;

  void celebratesBirthday() => age++;
  void addsSecondName(String secondName) => name = '$name $secondName';
}

Discussion

I've personally never used var in any of my projects, not a single time. If there is a rule such as unnecessary_final (which I feel rather negative about), I think the opposite should also exist so it can be set as a project standard in a collaborative context.

To my knowledge, the proposal:

  • conflicts with unnecessary_final and omit_local_variable_types and
  • overlaps with always_specify_types, prefer_final_fields, prefer_final_locals and prefer_final_in_for_each.

Despite numerous overlaps with existing rules, I'm still missing the one that hits the nail on the head, especially since the other rules are somewhat differently nuanced. For example, if I'd be fine with not having always_specify_types activated (because I'm absolutely okay with final _controller = TextEditingController(); vs. final TextEditingController _controller = TextEditingController();), var i = 0 would also be allowed if it is reassigned while all the other rules are turned on.

I understand that var is very popular among Flutter/Dart devs that follow a more practical approach. I also wouldn't add it to the standard library of lint rules, especially not for beginners. But I would definitely count myself to those who'd always have it activated if it exists.

Further reads:

https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#avoid-using-var-and-dynamic
https://dart.dev/guides/language/effective-dart/usage#do-follow-a-consistent-rule-for-var-and-final-on-local-variables
https://stackoverflow.com/questions/61183907/should-i-give-type
https://stackoverflow.com/questions/66836046/difference-between-var-and-other-more-specific-types-in-dart

Discussion checklist

  • List any existing rules this proposal complements, overlaps or conflict with.
  • List any relevant issues (reported here, the SDK Tracker, or elsewhere).
  • If there's any prior art (e.g., in other linters), please add references here.
  • If this proposal corresponds to Effective Dart or Flutter Style Guide advice, please call it out. (If there isn’t any corresponding advice, should there be?)
  • If this proposal is motivated by real-world examples, please provide as many details as you can. Demonstrating potential impact is especially valuable.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions