No opinion for or against, but I'd like to mention that the majority of our code base is xml, and the emphasis is on switching to groovy for everything, so the return on value from linting java might not be very high, especially since our problems in java are not primarily formatting issues, but rather design and architectural issues.
There are many great ideas for things to improve. The question is what to prioritize and bring to the top of your to do list. On Mon, Oct 14, 2019, 8:13 PM Mathieu Lirzin <[email protected]> wrote: > Hello, > > Linting [1] is a software engineering practice which make the code more > readable and maintainable by improving its consistency and avoiding > potential programming mistakes. Gradle provides a core plugin for the > ‘checkstyle’ tool [2][3] which implement a linting facility for the Java > language. > > I have opened OFBIZ-11251 [4] which proposes a patch for using this > Gradle plugin in OFBiz. > > With this patch when contributors will write Java code that do not match > the OFBiz coding convention [5] an error will be reported by ‘gradlew > check’ target. However when hacking running ‘gradlew’, ‘gradlew run’ or > ‘gradlew "ofbiz ..."’ will not bother integrators or contributors with > any linting errors. The idea is to recommend contributors to run > ‘gradlew check’ before sending a patch or committing one and maybe add a > Buildbot task for running such verification and blaming the faulty > committer. > > What do people think? > > If nobody oppose I will commit the OFBIZ-11251 patch in 3 days. > > [1] https://en.wikipedia.org/wiki/Lint_(software) > [2] https://checkstyle.org/ > [3] https://docs.gradle.org/current/userguide/checkstyle_plugin.html > [4] https://issues.apache.org/jira/browse/OFBIZ-11251 > [5] https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions > > -- > Mathieu Lirzin > GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37 >
