Trust me, I know what I’m doing
There are times when the compiler thinks the nullability of something might be a problem, but we know better. One example of this occurs in our unit tests when we are testing that the right exception is thrown when a value is omitted:
Here, the parameter for
WithSelection() is marked as non-nullable, so the compiler correctly gives us a warning, even though passing null is exactly what we should be doing as a part of the test.
Using the dammit operator is the right way to suppress the warning, even though it does look a bit quirky …
Updating all the things
It is a really good idea to stay on top of NuGet package updates. My experience is that updates get exponentially more difficult as the size of the update increases. For this reason, let’s take the time to upgrade all our NuGet packages to the latest versions.
Upgrading the static analysis tools we’re already using (Microsoft.CodeAnalysis.FxCopAnalyzers and Roslynator.Analyzers) to their latest releases is likely to trigger additional warnings. Also, our Desktop project isn’t using them at all, so we’ll add those references.
The vast majority of the new warnings have fairly unremarkable fixes:
- Add guard clauses to fail-fast if null appears unexpectedly;
- Use discards (
_) instead of naming unused parameters;
- Change variables that never change into constants;
- Mark classes as sealed;
- Mark fields as readonly.
When first planning this series, I expected that adding a new word and modifying an existing word would have substantial differences. Based on this expectation, the first editing viewmodel was the
AddVocabularyWordScreen, leaving room for a future viewmodel perhaps called
It now seems that the differences between adding and editing are minimal, not sufficient to justify different view-models (and different views as well). For this reason, I’ve gone through a renaming pass, transforming everything from