Remove redundant code + add type checker

[c-w]

This pull request contains several changes that will make maintenance of the project easier going forward:

• Inline simple wrapper methods.

• Remove unnecessary statements such as pass or return.

• Remove comments that only re-state information that's already in method names, parameter names, class names or type annotations.

• Make interface method signatures more specific so that all subclasses must expect the same arguments and return the same values.

All Submissions:

• [x] Have you followed the guidelines in our Contributing document?

• [x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

• [x] Does your PR follow our Code of Conduct?

• [x] Have you added an explanation of what your changes do and why you'd like us to include them?

• [x] Does each method or function "do one thing well"? Reviewers may recommend methods be split up for maintainability and testability.

• [x] Is this code designed to be testable? Not applicable: refactor

• [x] Is the code documented well? Not applicable: refactor

• [x] Does your submission pass existing tests (or update existing tests with documentation regarding the change)?

• [x] Have you added tests to cover your changes? Not applicable: refactor

• [x] Have you linted your code prior to submission?

• [x] Have you updated the documentation and README? Not applicable: refactor

• [x] Is PII treated correctly? In particular, make sure the code is not logging objects or strings that might contain PII (e.g. request headers). Not applicable: refactor

• [x] Have secrets been stripped before committing? Not applicable: refactor

[margaretmeehan]

Many of the comments you removed are certainly redundant, though I think commenting code can be helpful for people trying to understand a code base. Would like to hear better practices for how we can comment well.

[c-w]

@margaretmeehan Here's a concise "styleguide" for comments that I've seen successful on many projects in the past: ncrcoe/java-for-small-teams/style/comments. Other authors (e.g. Robert Martin in Clean Code) say similar things but with more words. In general, I'd try to avoid comments as much as possible since they tend to drift from the code over time as they're often not updated when the code is changed. I've often seen higher level documentation (e.g. diagrams of how the code interacts or how the architecture maps to the code) be more valuable and require less maintenance effort over time.