cb6d3b282a
Most of these are harmless, and are best fixed simply by removing the redundant check or assignment. The one in FlowType.compareBlocks, however, revealed a real problem. This code checks for nullness of `a` *after* having called a method on `a`. Assuming that `a` can indeed be `null` here, the check must come first to avoid a `NullPointerException`. In several places, I saw code of this form: if (thing == null) assert thing != null : ... ; I honestly don't understand the purpose of that `if` statement. Why not just have the `assert` statement there directly? I removed the seemingly irrelevant `if` statements in these cases, but if this is some intentional pattern, please explain it to me. In a few places where nullness is statically known but non-obvious, add assert statements to point out what's going on to help future developers. Upgrade future such warnings to errors to keep us moving in a cleaner direction. |
||
---|---|---|
.. | ||
.settings | ||
META-INF | ||
OSGI-INF/l10n | ||
source/org/scandroid | ||
.classpath | ||
.project | ||
build.properties | ||
mvncentral.xml | ||
pom.xml |