Using ‘checkstyle’ linting tool

[Mathieu Lirzin]

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

[taher]

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 <[hidden email]>
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
>

[Mathieu Lirzin]

Hello Taher,

Taher Alkhateeb <[hidden email]> writes:

> 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.

Sure I agree that linting is not very important compared to design and
architecture.  What is nice about automating trivial stuff such as
linting is that it allows to focus on the essential parts when doing
code reviews and not on the irrelevant details (indentation, naming
conventions, ...).

> 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.

The question I have is what is on top of your todo list Taher? :-)

Thanks for your input.

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[Mathieu Lirzin]

Hello Again,

Taher Alkhateeb <[hidden email]> writes:

> 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.

Towards the goal of adding actual value via linting, I have just found
CodeNarc [1] which provide a linting facility for Groovy and is easily
available via a Gradle plugin [2].

It might be interested to set this up for OFBiz.
             
[1] http://codenarc.sourceforge.net/
[2] https://docs.gradle.org/current/userguide/codenarc_plugin.html

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[Jacques Le Roux]

Le 19/10/2019 à 17:05, Mathieu Lirzin a écrit :

> Hello Again,
>
> Taher Alkhateeb <[hidden email]> writes:
>
>> 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.
> Towards the goal of adding actual value via linting, I have just found
> CodeNarc [1] which provide a linting facility for Groovy and is easily
> available via a Gradle plugin [2].
>
> It might be interested to set this up for OFBiz.
>                
> [1] http://codenarc.sourceforge.net/
> [2] https://docs.gradle.org/current/userguide/codenarc_plugin.html

Hi Mathieu,

You are most welcome: https://issues.apache.org/jira/browse/OFBIZ-11167 :)

Jacques

[Mathieu Lirzin]

Hello Jacques,

Jacques Le Roux <[hidden email]> writes:

> Le 19/10/2019 à 17:05, Mathieu Lirzin a écrit :
>> Hello Again,
>>
>> Taher Alkhateeb <[hidden email]> writes:
>>
>>> 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.
>> Towards the goal of adding actual value via linting, I have just found
>> CodeNarc [1] which provide a linting facility for Groovy and is easily
>> available via a Gradle plugin [2].
>>
>> It might be interested to set this up for OFBiz.
>>                [1] http://codenarc.sourceforge.net/
>> [2] https://docs.gradle.org/current/userguide/codenarc_plugin.html
>
> You are most welcome: https://issues.apache.org/jira/browse/OFBIZ-11167 :)

Excellent, we now just need a volunteer to do the work. :-)

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37