Does anyone have any experience with using static analysis on FRC code (especially in Java)? It seems like it’d be pretty straightforward to add spotbugs or pmd to a build.gradle file, but I’m curious if there are any other challenges (technical or human) to worry about? Do students have an easy time getting comfortable with these tools? Is the higher quality code worth the extra upfront cost of writing it? Has anyone had any success with any particular tools?
I rely heavily on clang-tidy in my professional C++ development and would love to reap similar benefits in FRC.
We use both spotbugs and pmd (and spotless) in the main WPILib build (albeit with a decent number of suppressions). They are powerful tools for keeping code clean, but I think the concern in team robot code would be having them slow down code updates, particularly at an event–the last thing you want to worry about when making a last-minute fix before a match is having PMD fail your build because you had one too many functions in a class, or you tripped a complexity threshold on a particular function, or have spotless fail because your indentation is wrong or a line was 4 characters too long. If you use them, make sure they’re set up to not fail the build, only emit warnings.
Thanks for responding, that makes sense. Is it possible to set it up so that these steps would emit warnings during local builds and errors/failures in a GitHub Action CI build?
Sure. The way we do that in WPILib is by passing a parameter to Gradle in the CI workflow (e.g. -PciBuild) and checking it in the Gradle script to set other options.
Not a java team, but I’ve played with the VS code sonarlint plugin for C++ and python code and have found it useful. Since this is just informative in VS code rather than being a build time potential blocker it works around the various scenarios in Peter’s post while still flagging stuff that should be fixed.
Config was straightforward for us since we were already generating compile_commands for our code, not sure how that maps to other teams though because our build env is weird.
Unfortunately spotless doesn’t allow for this behavior. You can either ignore a directory tree entirely as Peter mentioned (so those files aren’t formatted at all) or suppress errors on a specific file using ignoreErrorForPath (though I can’t seem to get that to work), but spotless does not have an option to warn instead of erroring for a directory.