Redeveloping WordTutor
Code Gardening

Continuing on the theme from our past two posts, we’ll address the remaining issues related to nullable types, as well as taming the rest of our current storm of compiler warnings.

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:

[Fact]
public void GivenNull_ThrowsExpectedException()
{
    var exception =
        Assert.Throws<ArgumentNullException>(
            () => _browser.WithSelection(null));
    exception.ParamName.Should().Be("word");
}

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 …

            () => _browser.WithSelection(null!));

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.

Addressing warnings

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.

Renaming

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 EditVocabularyWordScreen.

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 AddVocabularyWord to ModifyVocabularyWord.