Skip to content
This repository has been archived by the owner on May 27, 2024. It is now read-only.

Properly document nullable members or make them not nullable. #40

Open
safield opened this issue Aug 9, 2021 · 2 comments
Open

Properly document nullable members or make them not nullable. #40

safield opened this issue Aug 9, 2021 · 2 comments

Comments

@safield
Copy link

safield commented Aug 9, 2021

Some classes in this library have nullable type member variables, and it is not apparent why.

For example...

/// A line
class GeoJsonLine {
  /// Default constructor
  GeoJsonLine({this.geoSerie, this.name});

  /// The geometry data
  GeoSerie? geoSerie;

  /// The name of the line
  String? name;

  /// Serialize to a geojson feature string
  String? serializeFeature(Map<String, dynamic>? properties) =>
      geoSerie?.toGeoJsonFeatureString(properties);
}

Why is GeoSerie nullable? Does a GeoJsonLine make sense without a GeoSerie? Under what circumstances would this be null? Should this even be null?

If this member is never null, it should be typed as such. Libraries should try to never expose nullable types unless there is very good reason.

@synw
Copy link
Owner

synw commented Aug 10, 2021

@it-sam could you comment on this please? As you did the null safety migration

@it-sam
Copy link

it-sam commented Aug 29, 2021

@synw @safield is right, @safield Would you mind updating it?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants