Anything like that should be set up to use only a minimal subset of warnings that indicate genuine problems. Most of the ones I see on the linked page will be absurdly wrong at least some of the time.
For example, the warning not to use fully qualified class names (which is harmless and in some situations more robust) will get triggered multiple times on hundreds of classes containing generated code from the form editor. The insistence on tests containing the tool’s idea of what an assertion is is just silly - ever write a test of an API that calls you back on a background thread? If you want to write that clearly, you use assertions normally, catch them on the background thread and wait on a countdown latch or similar in the test thread, and rethrow the assertion error - and as soon as you’ve done that more than once, you’ll wrap that in a nice little lambda based call so your test code is clear (but it’s very unlikely there tool will recognize your assertions in that scope. And so forth. It’s not bad to have these things, but their authors generally compete on how big a list of hints they support, so there will be a lot of garbage, and you don’t want to wind up distorting the way you code to please a tool rather than using common sense. -Tim -- http://timboudreau.com
