Dart Language - issue

1. not_initialized_non_nullable_instance_field

Non-nullable instance field ‘{0}’ must be initialized.

Description

The analyzer produces this diagnostic(not_initialized_non_nullable_instance_field)when a field is declared and has all these characteristics:

• Has a type that’s potentially non-nullable
• Doesn’t have an initializer
• Isn’t marked as late

Examples

The following code produces this diagnostic because x is implicitly initialized to null when it isn’t allowed to be null:

class C {
  int x;
}

Similarly, the following code produces this diagnostic because x is implicitly initialized to null, when it isn’t allowed to be null, by one of the constructors, even though it’s initialized by other constructors:

class C {
  int x;

  C(this.x);

  C.n();
}

Common fixes

If there’s a reasonable default value for the field that’s the same for all instances, then add an initializer expression:

class C {
  int x = 0;
}

If the value of the field should be provided when an instance is created, then add a constructor that sets the value of the field or update an existing constructor:

class C {
  int x;

  C(this.x);
}

You can also mark the field as late, which removes the diagnostic, but if the field isn’t assigned a value before it’s accessed, then it results in an exception being thrown at runtime. This approach should only be used if you’re sure that the field will always be assigned before it’s referenced.

class C {
  late int x;
}

 

2.unchecked_use_of_nullable_value

A nullable expression can’t be used as a condition.

A nullable expression can’t be used as an iterator in a for-in loop.

A nullable expression can’t be used in a spread.

A nullable expression can’t be used in a yield-each statement.

The function can’t be unconditionally invoked because it can be ‘null’.

The method ‘{0}’ can’t be unconditionally invoked because the receiver can be ‘null’.

The operator ‘{0}’ can’t be unconditionally invoked because the receiver can be ‘null’.

The property ‘{0}’ can’t be unconditionally accessed because the receiver can be ‘null’.

Description

The analyzer produces this diagnostic when an expression whose type is potentially non-nullable is dereferenced without first verifying that the value isn’t null.

Example

The following code produces this diagnostic because s can be null at the point where it’s referenced:

void f(String? s) {
  if (s.length > 3) {
    // ...
  }
}

Common fixes

If the value really can be null, then add a test to ensure that members are only accessed when the value isn’t null:

void f(String? s) {
  if (s != null && s.length > 3) {
    // ...
  }
}

If the expression is a variable and the value should never be null, then change the type of the variable to be non-nullable:

void f(String s) {
  if (s.length > 3) {
    // ...
  }
}

If you believe that the value of the expression should never be null, but you can’t change the type of the variable, and you’re willing to risk having an exception thrown at runtime if you’re wrong, then you can assert that the value isn’t null:

void f(String? s) {
  if (s!.length > 3) {
    // ...
  }
}

 

3. prefer_final_locals

DO prefer declaring variables as final if they are not reassigned later in the code.

Declaring variables as final when possible is a good practice because it helps avoid accidental reassignments and allows the compiler to do optimizations.

void goodMethod() {
  final label = 'hola mundo! goodMethod';
  print(label);
}

void mutableCase() {
  var label = 'hola mundo! mutableCase';
  print(label);
  label = 'hello world';
  print(label);
}

 

4. avoid_positional_boolean_parameters

Positional boolean parameters are a bad practice because they are very ambiguous. Using named boolean parameters is much more readable because it inherently describes what the boolean value represents.

BAD:

Task(true);
Task(false);
ListBox(false, true, true);
Button(false);

GOOD:

Task.oneShot();
Task.repeating();
ListBox(scroll: true, showScrollbars: true);
Button(ButtonState.enabled);

 

 

참조 : https://dart.dev/tools/diagnostic-messages?utm_source=dartdev&utm_medium=redir&utm_id=diagcode&utm_content=not_initialized_non_nullable_instance_field#not_initialized_non_nullable_instance_field 

Diagnostic messages

5.  ?  !  ?. dart

https://cording-cossk3.tistory.com/82

[Flutter] Dart 문법 (class, ?, !, ?.)

 

6.dead_null_aware_expression

Description

The analyzer produces this diagnostic in two cases.

The first is when the left operand of an ?? operator can’t be null. The right operand is only evaluated if the left operand has the value null, and because the left operand can’t be null, the right operand is never evaluated.

The second is when the left-hand side of an assignment using the ??= operator can’t be null. The right-hand side is only evaluated if the left-hand side has the value null, and because the left-hand side can’t be null, the right-hand side is never evaluated.

Examples

The following code produces this diagnostic because x can’t be null:

int f(int x) {
  return x ?? 0;
}

The following code produces this diagnostic because f can’t be null:

class C {
  int f = -1;

  void m(int x) {
    f ??= x;
  }
}

Common fixes

If the diagnostic is reported for an ?? operator, then remove the ?? operator and the right operand:

int f(int x) {
  return x;
}

If the diagnostic is reported for an assignment, and the assignment isn’t needed, then remove the assignment:

class C {
  int f = -1;

  void m(int x) {
  }
}

If the assignment is needed, but should be based on a different condition, then rewrite the code to use = and the different condition:

class C {
  int f = -1;

  void m(int x) {
    if (f < 0) {
      f = x;
    }
  }
}

https://dart.dev/tools/diagnostic-messages?utm_source=dartdev&utm_medium=redir&utm_id=diagcode&utm_content=return_of_invalid_type#return_of_invalid_type 

Diagnostic messages