Code clean-up: Add own private static final LOGGER in each class#26
Conversation
|
This looks good, and is obviously something to keep an eye out for when reviewing pull requests. I'm going to merge this now. As a related question, though, do you know if this is something we can catch with static analysis? |
For "private static final Logger", maybe this can be achieved with Checkstyle (I did not check it). For "avoiding fields hiding others" => an IDE with appropriate setting can spot stuff like that... But for PR we need something at build/review time. Maybe a solution could be to introduce a tool like SonarQube (I hope they have an online hosted version with free plan for open-source, but I did not check it yet). |
|
I did a search and there's an slf4j plugin for Findbugs: https://github.com/KengoTODA/findbugs-slf4j that looks like it will do exactly this. It looks like only some of our sample code runs findbugs. I'll open an issue to generate discussion around static analysis options, since I'm really only familiar with those used in Scala projects. |
gradle support for SE server generator, fix junit tests, fix mainClass var in pom.xml Signed-off-by: aserkes <andrii.serkes@oracle.com>
Correct typo in the word join
Declaring
LOGGERasprivate static finalis a best practice in Java.https://stackoverflow.com/questions/6653520/why-do-we-declare-loggers-static-final
This is part of code cleanup to avoid fields hiding others.