adds null safety codelab

[ryanmcginnis]

• original snippets by @RedBrogdon/leaf
• adds analysis_options.yaml and pubspec.yaml based on existing examples
• adds examples to null_safety_codelab/bin/
• adds codelab to codelabs/
• updates side-nav.yml

staging: https://rm-dart.firebaseapp.com/codelabs/null-safety

[ryanmcginnis]

(CC @RedBrogdon)

[filiph]

LGTM with some comments

[ryanmcginnis]

I think you missed some of my review comments. (I started marking them, but then... it seemed silly to point them all out.) I saw them at https://github.com/dart-lang/site-www/pull/2983/files/a2236dac7a7adda644902a423252bfc18c01473f..6f5f3aad7cc30a9701ba929bb4f84906c8ee7a53.

thanks. i remember clicking the commit button for each suggestion. but i see now that i need to wait for the page to reload each time.

mit said that i could skip a second review from him.

[kwalrath]

I noticed a few more things, but I need to take another look with fresh eyes... tomorrow, I hope!

One more thing that I didn't notice until just now: the line between examples and exercises doesn't seem clear in this codelab. I think of examples as being things you can just run without modification, but I think every one of these DartPads except for final one ("Exercise: Late and lazy") requires some code changes.

Maybe they should all be examples? All except the last one exercises? Or maybe we should add a suggestion for how they could modify the last one?

In https://dart.dev/codelabs/async-await, exercises have a dark background and examples have a white background, but since the changes required here are so minor, differentiating the backgrounds seems perhaps unnecessary.

[kwalrath]

I think we're ready to go. I'll file a bug for follow-up work, like adding this to the /codelabs page and perhaps adding hints & tests to the examples.

[parlough]

Looks good overall, but some minor comments that can be implemented in a followup PR.

[parlough]

Seems like of should be Of to be consistent with the middle declaration and general naming standards.

[parlough]

It seems very not "Dart" like to include a setter method like this. Perhaps you could switch this example to use a getter and setter:

Late variables aren't generally a good idea to expose publicly anyway as you don't have much control over what others will do.

class Meal {
  late String _description;

  void set description(String str) => _description = str;

  String get description => _description;
}

void main() {
  final myMeal = Meal();
  myMeal.description = 'Feijoada!';
  print(myMeal.description);
}

[kwalrath]

Goodness, this sounds reasonable but we might need to think about it. I'll add it to that follow-up issue.