[DISCUSSION] Formatting in OFBiz OOTB

[Jacques Le Roux]

Hi,

Following https://s.apache.org/9pTo (OFBIZ-9877) and http://markmail.org/message/2bsp2fsbrdbd6dlb here is a discussion about Formatting in OFBiz OOTB.

Note we had already discussions in the past and these should be used as references in this discussion
http://markmail.org/message/calbmwzd4nj32l4g
http://markmail.org/message/qx3base6tolxfcjf
http://markmail.org/message/t2am3t6eev6zk5bj

I don't want to repeat myself too much but for the use of readers here, here are some points I think are important.

Long in the past I suggested to share and, use as much as possible, the same formatter (it must come from Eclipse because IntelliJ can load it but not
the reverse). But there has never been a consensual agreement on that with the team. Years ago I proposed my own formatter. It's there as an
attachment of https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions but for a reason no longer downloadable. So I added the one I use
now: https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=776602 
<https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=7766027>

To me (and others in above discussions, see notably Jacopo's point in the 1st convo) the most important thing is to not arbitrarily cut lines with
automated formatter when creating fixing, improving or refactoring patch (it could makes sense in formatting patch, but do we really want that?).

IMO Jacopo's point is the simplest solution to this problem: simply don't format when patching, or at least do that in specific patches but we then
need to agree about lines lengths and IMO the longer the better (I use 180 for code and comments, but of course rarely get so far)

In OFBIZ-9877 Michael said
     <<I would really like to have a coding style where we can rely on, that would make things much easier to maintain an even looking code. Maybe we
should decide on a mandatory formatting and do a big reformatting session with no functional changes to have a common ground to continue with. But
this is another issue.>>
To be clear this is not top priority and not the subject of the current discussion

About Formatting vs. refactoring:
My point is: refactoring is not formatting and because refactoring is by itself already something which needs careful reviews, adding lines of
formatting, mix 2 types of things. So, again, the subject of the current discussion, it's not functional vs not functional; but no formatting,
especially lines cut, in commits but formatting commits.

Another important point is the removing of trailing blanks. Why this one also? Because both lines cuts and trailing blanks removing are pure
formatting things which when automated generated a lot of "false changes" in patches/commits and make their reviews harder. Most of the time other
formatting points, like when and where to cut long method signature, EntityQuery.use(delegator).from() stuff, etc. should not be a problem. If you
have ideas about that please share.

So that's mostly it, and the question is: should we share an IDE auto-formatter? If so I propose to start from mine and refine, else what?

I understand people not using an IDE will feel less concerned. But I guess they can also have an auto-formatter, it's maybe "just" harder to share :/

And about the reasons and goals of this discussion, I see at least

 1. easier review for patches (this is currently not a problem, people no longer do that) and commits (but specific formatting commits).
 2. easier merging when coming from outside
 3. please adds your...

I propose to use a lazy consensus for this discussion, we don't want to vote about formatting ;)

Thanks

Jacques

[taher]

I'm not sure what is the proposal here

On Tue, Dec 19, 2017 at 3:31 PM, Jacques Le Roux
<[hidden email]> wrote:

> Hi,
>
> Following https://s.apache.org/9pTo (OFBIZ-9877) and
> http://markmail.org/message/2bsp2fsbrdbd6dlb here is a discussion about
> Formatting in OFBiz OOTB.
>
> Note we had already discussions in the past and these should be used as
> references in this discussion
> http://markmail.org/message/calbmwzd4nj32l4g
> http://markmail.org/message/qx3base6tolxfcjf
> http://markmail.org/message/t2am3t6eev6zk5bj
>
> I don't want to repeat myself too much but for the use of readers here, here
> are some points I think are important.
>
> Long in the past I suggested to share and, use as much as possible, the same
> formatter (it must come from Eclipse because IntelliJ can load it but not
> the reverse). But there has never been a consensual agreement on that with
> the team. Years ago I proposed my own formatter. It's there as an attachment
> of https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions but
> for a reason no longer downloadable. So I added the one I use now:
> https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=776602
> <https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=7766027>
>
> To me (and others in above discussions, see notably Jacopo's point in the
> 1st convo) the most important thing is to not arbitrarily cut lines with
> automated formatter when creating fixing, improving or refactoring patch (it
> could makes sense in formatting patch, but do we really want that?).
>
> IMO Jacopo's point is the simplest solution to this problem: simply don't
> format when patching, or at least do that in specific patches but we then
> need to agree about lines lengths and IMO the longer the better (I use 180
> for code and comments, but of course rarely get so far)
>
> In OFBIZ-9877 Michael said
>     <<I would really like to have a coding style where we can rely on, that
> would make things much easier to maintain an even looking code. Maybe we
> should decide on a mandatory formatting and do a big reformatting session
> with no functional changes to have a common ground to continue with. But
> this is another issue.>>
> To be clear this is not top priority and not the subject of the current
> discussion
>
> About Formatting vs. refactoring:
> My point is: refactoring is not formatting and because refactoring is by
> itself already something which needs careful reviews, adding lines of
> formatting, mix 2 types of things. So, again, the subject of the current
> discussion, it's not functional vs not functional; but no formatting,
> especially lines cut, in commits but formatting commits.
>
> Another important point is the removing of trailing blanks. Why this one
> also? Because both lines cuts and trailing blanks removing are pure
> formatting things which when automated generated a lot of "false changes" in
> patches/commits and make their reviews harder. Most of the time other
> formatting points, like when and where to cut long method signature,
> EntityQuery.use(delegator).from() stuff, etc. should not be a problem. If
> you have ideas about that please share.
>
> So that's mostly it, and the question is: should we share an IDE
> auto-formatter? If so I propose to start from mine and refine, else what?
>
> I understand people not using an IDE will feel less concerned. But I guess
> they can also have an auto-formatter, it's maybe "just" harder to share :/
>
> And about the reasons and goals of this discussion, I see at least
>
> 1. easier review for patches (this is currently not a problem, people no
> longer do that) and commits (but specific formatting commits).
> 2. easier merging when coming from outside
> 3. please adds your...
>
> I propose to use a lazy consensus for this discussion, we don't want to vote
> about formatting ;)
>
> Thanks
>
> Jacques
>

[Jacques Le Roux]

Actually it's not a [PROPOSAL] it's a [DISCUSSION]... kidding (but nevertheless you can add your point 3 after mine ;))

Seriously: after your request to open a discussion: http://markmail.org/message/2bsp2fsbrdbd6dlb I reported/wrote in this thread some facts mostly
based on our previous discussion with Michael at OFBIZ-9877

The proposal would be simple. I suggest all committers to use an auto-formatter for Java code (for Groovy I don't know yet) and that it should be, as
much as possible, the same for all committers.

So we need to define the rules, and I propose as a basis for this discussion the formatter I use in Eclipse which is derived from the basic Eclipse
one for Java conventions. BTW I just updated it again (for Java 8 & 9), mine was based on an old one.

The main changes I introduced is a line length of 180, to avoid automated lines split in patches (180 sounds reasonable and a good compromise to me 
(below "-<setting id=" correspond to my changes).

     -<setting id="org.eclipse.jdt.core.formatter.comment.line_length" value="180"/>
     +<setting id="org.eclipse.jdt.core.formatter.comment.line_length" value="80"/>

Here are other minors changes I did, I have no strong opinions about them (I did more in the past but finally simplified). Beware the changes are
reversed

     -<setting id="org.eclipse.jdt.core.formatter.keep_then_statement_on_same_line" value="true"/>
     +<setting id="org.eclipse.jdt.core.formatter.keep_then_statement_on_same_line" value="false"/>
     -<setting id="org.eclipse.jdt.core.formatter.use_on_off_tags" value="true"/>
     +<setting id="org.eclipse.jdt.core.formatter.use_on_off_tags" value="false"/>
     -<setting id="org.eclipse.jdt.core.formatter.keep_else_statement_on_same_line" value="true"/>
     +<setting id="org.eclipse.jdt.core.formatter.keep_else_statement_on_same_line" value="false"/>
     -<setting id="org.eclipse.jdt.core.formatter.indent_switchstatements_compare_to_switch" value="true"/>
     +<setting id="org.eclipse.jdt.core.formatter.indent_switchstatements_compare_to_switch" value="false"/>
     -<setting id="org.eclipse.jdt.core.formatter.keep_imple_if_on_one_line" value="true"/>
     +<setting id="org.eclipse.jdt.core.formatter.keep_imple_if_on_one_line" value="false"/>
     -<setting id="org.eclipse.jdt.core.formatter.wrap_outer_expressions_when_nested" value="true"/>
     +<setting id="org.eclipse.jdt.core.formatter.wrap_outer_expressions_when_nested" value="false"/>

Of course, an auto-formatter is not a silver bullet and we need to accept and define exceptions.

For instance, one come instantly to my mind: when using

EntityQuery.use(delegator).from()...

It easier to read when sub-expressions are split by lines, same is true for Java 8 Streams.

I think we can also accept different ways of splitting method signatures and other minor things that we can adjust if needed later (eg the 2nd block
of my changes)

HTH

Jacques





Le 21/12/2017 à 12:53, Taher Alkhateeb a écrit :

> I'm not sure what is the proposal here
>
> On Tue, Dec 19, 2017 at 3:31 PM, Jacques Le Roux
> <[hidden email]> wrote:
>> Hi,
>>
>> Following https://s.apache.org/9pTo (OFBIZ-9877) and
>> http://markmail.org/message/2bsp2fsbrdbd6dlb here is a discussion about
>> Formatting in OFBiz OOTB.
>>
>> Note we had already discussions in the past and these should be used as
>> references in this discussion
>> http://markmail.org/message/calbmwzd4nj32l4g
>> http://markmail.org/message/qx3base6tolxfcjf
>> http://markmail.org/message/t2am3t6eev6zk5bj
>>
>> I don't want to repeat myself too much but for the use of readers here, here
>> are some points I think are important.
>>
>> Long in the past I suggested to share and, use as much as possible, the same
>> formatter (it must come from Eclipse because IntelliJ can load it but not
>> the reverse). But there has never been a consensual agreement on that with
>> the team. Years ago I proposed my own formatter. It's there as an attachment
>> of https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions but
>> for a reason no longer downloadable. So I added the one I use now:
>> https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=776602
>> <https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=7766027>
>>
>> To me (and others in above discussions, see notably Jacopo's point in the
>> 1st convo) the most important thing is to not arbitrarily cut lines with
>> automated formatter when creating fixing, improving or refactoring patch (it
>> could makes sense in formatting patch, but do we really want that?).
>>
>> IMO Jacopo's point is the simplest solution to this problem: simply don't
>> format when patching, or at least do that in specific patches but we then
>> need to agree about lines lengths and IMO the longer the better (I use 180
>> for code and comments, but of course rarely get so far)
>>
>> In OFBIZ-9877 Michael said
>>      <<I would really like to have a coding style where we can rely on, that
>> would make things much easier to maintain an even looking code. Maybe we
>> should decide on a mandatory formatting and do a big reformatting session
>> with no functional changes to have a common ground to continue with. But
>> this is another issue.>>
>> To be clear this is not top priority and not the subject of the current
>> discussion
>>
>> About Formatting vs. refactoring:
>> My point is: refactoring is not formatting and because refactoring is by
>> itself already something which needs careful reviews, adding lines of
>> formatting, mix 2 types of things. So, again, the subject of the current
>> discussion, it's not functional vs not functional; but no formatting,
>> especially lines cut, in commits but formatting commits.
>>
>> Another important point is the removing of trailing blanks. Why this one
>> also? Because both lines cuts and trailing blanks removing are pure
>> formatting things which when automated generated a lot of "false changes" in
>> patches/commits and make their reviews harder. Most of the time other
>> formatting points, like when and where to cut long method signature,
>> EntityQuery.use(delegator).from() stuff, etc. should not be a problem. If
>> you have ideas about that please share.
>>
>> So that's mostly it, and the question is: should we share an IDE
>> auto-formatter? If so I propose to start from mine and refine, else what?
>>
>> I understand people not using an IDE will feel less concerned. But I guess
>> they can also have an auto-formatter, it's maybe "just" harder to share :/
>>
>> And about the reasons and goals of this discussion, I see at least
>>
>> 1. easier review for patches (this is currently not a problem, people no
>> longer do that) and commits (but specific formatting commits).
>> 2. easier merging when coming from outside
>> 3. please adds your...
>>
>> I propose to use a lazy consensus for this discussion, we don't want to vote
>> about formatting ;)
>>
>> Thanks
>>
>> Jacques
>>

[Jacques Le Roux]

I just added a link to my formatter at https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions


Le 21/12/2017 à 15:55, Jacques Le Roux a écrit :

> Actually it's not a [PROPOSAL] it's a [DISCUSSION]... kidding (but nevertheless you can add your point 3 after mine ;))
>
> Seriously: after your request to open a discussion: http://markmail.org/message/2bsp2fsbrdbd6dlb I reported/wrote in this thread some facts mostly
> based on our previous discussion with Michael at OFBIZ-9877
>
> The proposal would be simple. I suggest all committers to use an auto-formatter for Java code (for Groovy I don't know yet) and that it should be,
> as much as possible, the same for all committers.
>
> So we need to define the rules, and I propose as a basis for this discussion the formatter I use in Eclipse which is derived from the basic Eclipse
> one for Java conventions. BTW I just updated it again (for Java 8 & 9), mine was based on an old one.
>
> The main changes I introduced is a line length of 180, to avoid automated lines split in patches (180 sounds reasonable and a good compromise to me 
> (below "-<setting id=" correspond to my changes).
>
>     -<setting id="org.eclipse.jdt.core.formatter.comment.line_length" value="180"/>
>     +<setting id="org.eclipse.jdt.core.formatter.comment.line_length" value="80"/>
>
> Here are other minors changes I did, I have no strong opinions about them (I did more in the past but finally simplified). Beware the changes are
> reversed
>
>     -<setting id="org.eclipse.jdt.core.formatter.keep_then_statement_on_same_line" value="true"/>
>     +<setting id="org.eclipse.jdt.core.formatter.keep_then_statement_on_same_line" value="false"/>
>     -<setting id="org.eclipse.jdt.core.formatter.use_on_off_tags" value="true"/>
>     +<setting id="org.eclipse.jdt.core.formatter.use_on_off_tags" value="false"/>
>     -<setting id="org.eclipse.jdt.core.formatter.keep_else_statement_on_same_line" value="true"/>
>     +<setting id="org.eclipse.jdt.core.formatter.keep_else_statement_on_same_line" value="false"/>
>     -<setting id="org.eclipse.jdt.core.formatter.indent_switchstatements_compare_to_switch" value="true"/>
>     +<setting id="org.eclipse.jdt.core.formatter.indent_switchstatements_compare_to_switch" value="false"/>
>     -<setting id="org.eclipse.jdt.core.formatter.keep_imple_if_on_one_line" value="true"/>
>     +<setting id="org.eclipse.jdt.core.formatter.keep_imple_if_on_one_line" value="false"/>
>     -<setting id="org.eclipse.jdt.core.formatter.wrap_outer_expressions_when_nested" value="true"/>
>     +<setting id="org.eclipse.jdt.core.formatter.wrap_outer_expressions_when_nested" value="false"/>
>
> Of course, an auto-formatter is not a silver bullet and we need to accept and define exceptions.
>
> For instance, one come instantly to my mind: when using
>
> EntityQuery.use(delegator).from()...
>
> It easier to read when sub-expressions are split by lines, same is true for Java 8 Streams.
>
> I think we can also accept different ways of splitting method signatures and other minor things that we can adjust if needed later (eg the 2nd block
> of my changes)
>
> HTH
>
> Jacques
>
>
>
>
>
> Le 21/12/2017 à 12:53, Taher Alkhateeb a écrit :
>> I'm not sure what is the proposal here
>>
>> On Tue, Dec 19, 2017 at 3:31 PM, Jacques Le Roux
>> <[hidden email]> wrote:
>>> Hi,
>>>
>>> Following https://s.apache.org/9pTo (OFBIZ-9877) and
>>> http://markmail.org/message/2bsp2fsbrdbd6dlb here is a discussion about
>>> Formatting in OFBiz OOTB.
>>>
>>> Note we had already discussions in the past and these should be used as
>>> references in this discussion
>>> http://markmail.org/message/calbmwzd4nj32l4g
>>> http://markmail.org/message/qx3base6tolxfcjf
>>> http://markmail.org/message/t2am3t6eev6zk5bj
>>>
>>> I don't want to repeat myself too much but for the use of readers here, here
>>> are some points I think are important.
>>>
>>> Long in the past I suggested to share and, use as much as possible, the same
>>> formatter (it must come from Eclipse because IntelliJ can load it but not
>>> the reverse). But there has never been a consensual agreement on that with
>>> the team. Years ago I proposed my own formatter. It's there as an attachment
>>> of https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions but
>>> for a reason no longer downloadable. So I added the one I use now:
>>> https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=776602
>>> <https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=7766027>
>>>
>>> To me (and others in above discussions, see notably Jacopo's point in the
>>> 1st convo) the most important thing is to not arbitrarily cut lines with
>>> automated formatter when creating fixing, improving or refactoring patch (it
>>> could makes sense in formatting patch, but do we really want that?).
>>>
>>> IMO Jacopo's point is the simplest solution to this problem: simply don't
>>> format when patching, or at least do that in specific patches but we then
>>> need to agree about lines lengths and IMO the longer the better (I use 180
>>> for code and comments, but of course rarely get so far)
>>>
>>> In OFBIZ-9877 Michael said
>>>      <<I would really like to have a coding style where we can rely on, that
>>> would make things much easier to maintain an even looking code. Maybe we
>>> should decide on a mandatory formatting and do a big reformatting session
>>> with no functional changes to have a common ground to continue with. But
>>> this is another issue.>>
>>> To be clear this is not top priority and not the subject of the current
>>> discussion
>>>
>>> About Formatting vs. refactoring:
>>> My point is: refactoring is not formatting and because refactoring is by
>>> itself already something which needs careful reviews, adding lines of
>>> formatting, mix 2 types of things. So, again, the subject of the current
>>> discussion, it's not functional vs not functional; but no formatting,
>>> especially lines cut, in commits but formatting commits.
>>>
>>> Another important point is the removing of trailing blanks. Why this one
>>> also? Because both lines cuts and trailing blanks removing are pure
>>> formatting things which when automated generated a lot of "false changes" in
>>> patches/commits and make their reviews harder. Most of the time other
>>> formatting points, like when and where to cut long method signature,
>>> EntityQuery.use(delegator).from() stuff, etc. should not be a problem. If
>>> you have ideas about that please share.
>>>
>>> So that's mostly it, and the question is: should we share an IDE
>>> auto-formatter? If so I propose to start from mine and refine, else what?
>>>
>>> I understand people not using an IDE will feel less concerned. But I guess
>>> they can also have an auto-formatter, it's maybe "just" harder to share :/
>>>
>>> And about the reasons and goals of this discussion, I see at least
>>>
>>> 1. easier review for patches (this is currently not a problem, people no
>>> longer do that) and commits (but specific formatting commits).
>>> 2. easier merging when coming from outside
>>> 3. please adds your...
>>>
>>> I propose to use a lazy consensus for this discussion, we don't want to vote
>>> about formatting ;)
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>
>

[taher]

okay so I still am not quite sure what you're trying to suggest or
promote in this discussion. Do you encourage changing or updating the
coding conventions? if yes how? Do you wish to enforce or encourage
formatting tools? Are you only discussing line width? We can have a
discussion based on your feedback I guess.

Either way, when it comes to line width, I would suggest that yeah
maybe 80 is too narrow for the modern age, but 180 could be too wide
and is an indicator of a code smell (if we're talking about Java). If
you can't say whatever you want to say in say 100 or 120 characters or
so then it might be indicative of a problematic code design.

On Thu, Dec 21, 2017 at 6:09 PM, Jacques Le Roux
<[hidden email]> wrote:

> I just added a link to my formatter at
> https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions
>
>
>
> Le 21/12/2017 à 15:55, Jacques Le Roux a écrit :
>>
>> Actually it's not a [PROPOSAL] it's a [DISCUSSION]... kidding (but
>> nevertheless you can add your point 3 after mine ;))
>>
>> Seriously: after your request to open a discussion:
>> http://markmail.org/message/2bsp2fsbrdbd6dlb I reported/wrote in this thread
>> some facts mostly based on our previous discussion with Michael at
>> OFBIZ-9877
>>
>> The proposal would be simple. I suggest all committers to use an
>> auto-formatter for Java code (for Groovy I don't know yet) and that it
>> should be, as much as possible, the same for all committers.
>>
>> So we need to define the rules, and I propose as a basis for this
>> discussion the formatter I use in Eclipse which is derived from the basic
>> Eclipse one for Java conventions. BTW I just updated it again (for Java 8 &
>> 9), mine was based on an old one.
>>
>> The main changes I introduced is a line length of 180, to avoid automated
>> lines split in patches (180 sounds reasonable and a good compromise to me
>> (below "-<setting id=" correspond to my changes).
>>
>>     -<setting id="org.eclipse.jdt.core.formatter.comment.line_length"
>> value="180"/>
>>     +<setting id="org.eclipse.jdt.core.formatter.comment.line_length"
>> value="80"/>
>>
>> Here are other minors changes I did, I have no strong opinions about them
>> (I did more in the past but finally simplified). Beware the changes are
>> reversed
>>
>>     -<setting
>> id="org.eclipse.jdt.core.formatter.keep_then_statement_on_same_line"
>> value="true"/>
>>     +<setting
>> id="org.eclipse.jdt.core.formatter.keep_then_statement_on_same_line"
>> value="false"/>
>>     -<setting id="org.eclipse.jdt.core.formatter.use_on_off_tags"
>> value="true"/>
>>     +<setting id="org.eclipse.jdt.core.formatter.use_on_off_tags"
>> value="false"/>
>>     -<setting
>> id="org.eclipse.jdt.core.formatter.keep_else_statement_on_same_line"
>> value="true"/>
>>     +<setting
>> id="org.eclipse.jdt.core.formatter.keep_else_statement_on_same_line"
>> value="false"/>
>>     -<setting
>> id="org.eclipse.jdt.core.formatter.indent_switchstatements_compare_to_switch"
>> value="true"/>
>>     +<setting
>> id="org.eclipse.jdt.core.formatter.indent_switchstatements_compare_to_switch"
>> value="false"/>
>>     -<setting
>> id="org.eclipse.jdt.core.formatter.keep_imple_if_on_one_line" value="true"/>
>>     +<setting
>> id="org.eclipse.jdt.core.formatter.keep_imple_if_on_one_line"
>> value="false"/>
>>     -<setting
>> id="org.eclipse.jdt.core.formatter.wrap_outer_expressions_when_nested"
>> value="true"/>
>>     +<setting
>> id="org.eclipse.jdt.core.formatter.wrap_outer_expressions_when_nested"
>> value="false"/>
>>
>> Of course, an auto-formatter is not a silver bullet and we need to accept
>> and define exceptions.
>>
>> For instance, one come instantly to my mind: when using
>>
>> EntityQuery.use(delegator).from()...
>>
>> It easier to read when sub-expressions are split by lines, same is true
>> for Java 8 Streams.
>>
>> I think we can also accept different ways of splitting method signatures
>> and other minor things that we can adjust if needed later (eg the 2nd block
>> of my changes)
>>
>> HTH
>>
>> Jacques
>>
>>
>>
>>
>>
>> Le 21/12/2017 à 12:53, Taher Alkhateeb a écrit :
>>>
>>> I'm not sure what is the proposal here
>>>
>>> On Tue, Dec 19, 2017 at 3:31 PM, Jacques Le Roux
>>> <[hidden email]> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Following https://s.apache.org/9pTo (OFBIZ-9877) and
>>>> http://markmail.org/message/2bsp2fsbrdbd6dlb here is a discussion about
>>>> Formatting in OFBiz OOTB.
>>>>
>>>> Note we had already discussions in the past and these should be used as
>>>> references in this discussion
>>>> http://markmail.org/message/calbmwzd4nj32l4g
>>>> http://markmail.org/message/qx3base6tolxfcjf
>>>> http://markmail.org/message/t2am3t6eev6zk5bj
>>>>
>>>> I don't want to repeat myself too much but for the use of readers here,
>>>> here
>>>> are some points I think are important.
>>>>
>>>> Long in the past I suggested to share and, use as much as possible, the
>>>> same
>>>> formatter (it must come from Eclipse because IntelliJ can load it but
>>>> not
>>>> the reverse). But there has never been a consensual agreement on that
>>>> with
>>>> the team. Years ago I proposed my own formatter. It's there as an
>>>> attachment
>>>> of https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions
>>>> but
>>>> for a reason no longer downloadable. So I added the one I use now:
>>>>
>>>> https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=776602
>>>>
>>>> <https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=7766027>
>>>>
>>>> To me (and others in above discussions, see notably Jacopo's point in
>>>> the
>>>> 1st convo) the most important thing is to not arbitrarily cut lines with
>>>> automated formatter when creating fixing, improving or refactoring patch
>>>> (it
>>>> could makes sense in formatting patch, but do we really want that?).
>>>>
>>>> IMO Jacopo's point is the simplest solution to this problem: simply
>>>> don't
>>>> format when patching, or at least do that in specific patches but we
>>>> then
>>>> need to agree about lines lengths and IMO the longer the better (I use
>>>> 180
>>>> for code and comments, but of course rarely get so far)
>>>>
>>>> In OFBIZ-9877 Michael said
>>>>      <<I would really like to have a coding style where we can rely on,
>>>> that
>>>> would make things much easier to maintain an even looking code. Maybe we
>>>> should decide on a mandatory formatting and do a big reformatting
>>>> session
>>>> with no functional changes to have a common ground to continue with. But
>>>> this is another issue.>>
>>>> To be clear this is not top priority and not the subject of the current
>>>> discussion
>>>>
>>>> About Formatting vs. refactoring:
>>>> My point is: refactoring is not formatting and because refactoring is by
>>>> itself already something which needs careful reviews, adding lines of
>>>> formatting, mix 2 types of things. So, again, the subject of the current
>>>> discussion, it's not functional vs not functional; but no formatting,
>>>> especially lines cut, in commits but formatting commits.
>>>>
>>>> Another important point is the removing of trailing blanks. Why this one
>>>> also? Because both lines cuts and trailing blanks removing are pure
>>>> formatting things which when automated generated a lot of "false
>>>> changes" in
>>>> patches/commits and make their reviews harder. Most of the time other
>>>> formatting points, like when and where to cut long method signature,
>>>> EntityQuery.use(delegator).from() stuff, etc. should not be a problem.
>>>> If
>>>> you have ideas about that please share.
>>>>
>>>> So that's mostly it, and the question is: should we share an IDE
>>>> auto-formatter? If so I propose to start from mine and refine, else
>>>> what?
>>>>
>>>> I understand people not using an IDE will feel less concerned. But I
>>>> guess
>>>> they can also have an auto-formatter, it's maybe "just" harder to share
>>>> :/
>>>>
>>>> And about the reasons and goals of this discussion, I see at least
>>>>
>>>> 1. easier review for patches (this is currently not a problem, people no
>>>> longer do that) and commits (but specific formatting commits).
>>>> 2. easier merging when coming from outside
>>>> 3. please adds your...
>>>>
>>>> I propose to use a lazy consensus for this discussion, we don't want to
>>>> vote
>>>> about formatting ;)
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>>
>>
>>
>

[Jacques Le Roux]

Yes it's mostly about lines split. I prefer 180 chars by line, but 120 would be fine with me,  I understand it's easier for laptop users.

One thing I forgot to speak about is removing trailing blanks in patches/commits.

So far we agreed to not do that. But Michael prefers to do it, and it seems apart me nobody spoke about that.

I was initially doing so, but I got convinced to stop because it's  real pain for review. So I think we want to discuss that again also...

For all the rest, it's sometimes a pain to backport or contribute patches when the formatting is not the same but by experience I know it's hard to
convince people for an unique format.

For instance when to use "if () {expression}" on one line or not (this is not Java convention, but sometimes useful), or where to split method
signatures (120 chars is maybe long there), etc.

The problem I crossed while reviewing Michael's bursts of patches was increased by "little" things like that, but yes mostly lines split and removed
trailing blanks.

On the other hand, as Michael advocated, this can be done in formatting patches (where nothing else is done but formatting).

I think we should wrote that clearly in coding conventions when we will get a consensus.

Jacques


Le 21/12/2017 à 16:20, Taher Alkhateeb a écrit :

> okay so I still am not quite sure what you're trying to suggest or
> promote in this discussion. Do you encourage changing or updating the
> coding conventions? if yes how? Do you wish to enforce or encourage
> formatting tools? Are you only discussing line width? We can have a
> discussion based on your feedback I guess.
>
> Either way, when it comes to line width, I would suggest that yeah
> maybe 80 is too narrow for the modern age, but 180 could be too wide
> and is an indicator of a code smell (if we're talking about Java). If
> you can't say whatever you want to say in say 100 or 120 characters or
> so then it might be indicative of a problematic code design.
>
> On Thu, Dec 21, 2017 at 6:09 PM, Jacques Le Roux
> <[hidden email]>  wrote:
>> I just added a link to my formatter at
>> https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions
>>
>>
>>
>> Le 21/12/2017 à 15:55, Jacques Le Roux a écrit :
>>> Actually it's not a [PROPOSAL] it's a [DISCUSSION]... kidding (but
>>> nevertheless you can add your point 3 after mine ;))
>>>
>>> Seriously: after your request to open a discussion:
>>> http://markmail.org/message/2bsp2fsbrdbd6dlb  I reported/wrote in this thread
>>> some facts mostly based on our previous discussion with Michael at
>>> OFBIZ-9877
>>>
>>> The proposal would be simple. I suggest all committers to use an
>>> auto-formatter for Java code (for Groovy I don't know yet) and that it
>>> should be, as much as possible, the same for all committers.
>>>
>>> So we need to define the rules, and I propose as a basis for this
>>> discussion the formatter I use in Eclipse which is derived from the basic
>>> Eclipse one for Java conventions. BTW I just updated it again (for Java 8 &
>>> 9), mine was based on an old one.
>>>
>>> The main changes I introduced is a line length of 180, to avoid automated
>>> lines split in patches (180 sounds reasonable and a good compromise to me
>>> (below "-<setting id=" correspond to my changes).
>>>
>>>      -<setting id="org.eclipse.jdt.core.formatter.comment.line_length"
>>> value="180"/>
>>>      +<setting id="org.eclipse.jdt.core.formatter.comment.line_length"
>>> value="80"/>
>>>
>>> Here are other minors changes I did, I have no strong opinions about them
>>> (I did more in the past but finally simplified). Beware the changes are
>>> reversed
>>>
>>>      -<setting
>>> id="org.eclipse.jdt.core.formatter.keep_then_statement_on_same_line"
>>> value="true"/>
>>>      +<setting
>>> id="org.eclipse.jdt.core.formatter.keep_then_statement_on_same_line"
>>> value="false"/>
>>>      -<setting id="org.eclipse.jdt.core.formatter.use_on_off_tags"
>>> value="true"/>
>>>      +<setting id="org.eclipse.jdt.core.formatter.use_on_off_tags"
>>> value="false"/>
>>>      -<setting
>>> id="org.eclipse.jdt.core.formatter.keep_else_statement_on_same_line"
>>> value="true"/>
>>>      +<setting
>>> id="org.eclipse.jdt.core.formatter.keep_else_statement_on_same_line"
>>> value="false"/>
>>>      -<setting
>>> id="org.eclipse.jdt.core.formatter.indent_switchstatements_compare_to_switch"
>>> value="true"/>
>>>      +<setting
>>> id="org.eclipse.jdt.core.formatter.indent_switchstatements_compare_to_switch"
>>> value="false"/>
>>>      -<setting
>>> id="org.eclipse.jdt.core.formatter.keep_imple_if_on_one_line" value="true"/>
>>>      +<setting
>>> id="org.eclipse.jdt.core.formatter.keep_imple_if_on_one_line"
>>> value="false"/>
>>>      -<setting
>>> id="org.eclipse.jdt.core.formatter.wrap_outer_expressions_when_nested"
>>> value="true"/>
>>>      +<setting
>>> id="org.eclipse.jdt.core.formatter.wrap_outer_expressions_when_nested"
>>> value="false"/>
>>>
>>> Of course, an auto-formatter is not a silver bullet and we need to accept
>>> and define exceptions.
>>>
>>> For instance, one come instantly to my mind: when using
>>>
>>> EntityQuery.use(delegator).from()...
>>>
>>> It easier to read when sub-expressions are split by lines, same is true
>>> for Java 8 Streams.
>>>
>>> I think we can also accept different ways of splitting method signatures
>>> and other minor things that we can adjust if needed later (eg the 2nd block
>>> of my changes)
>>>
>>> HTH
>>>
>>> Jacques
>>>
>>>
>>>
>>>
>>>
>>> Le 21/12/2017 à 12:53, Taher Alkhateeb a écrit :
>>>> I'm not sure what is the proposal here
>>>>
>>>> On Tue, Dec 19, 2017 at 3:31 PM, Jacques Le Roux
>>>> <[hidden email]>  wrote:
>>>>> Hi,
>>>>>
>>>>> Followinghttps://s.apache.org/9pTo  (OFBIZ-9877) and
>>>>> http://markmail.org/message/2bsp2fsbrdbd6dlb  here is a discussion about
>>>>> Formatting in OFBiz OOTB.
>>>>>
>>>>> Note we had already discussions in the past and these should be used as
>>>>> references in this discussion
>>>>> http://markmail.org/message/calbmwzd4nj32l4g
>>>>> http://markmail.org/message/qx3base6tolxfcjf
>>>>> http://markmail.org/message/t2am3t6eev6zk5bj
>>>>>
>>>>> I don't want to repeat myself too much but for the use of readers here,
>>>>> here
>>>>> are some points I think are important.
>>>>>
>>>>> Long in the past I suggested to share and, use as much as possible, the
>>>>> same
>>>>> formatter (it must come from Eclipse because IntelliJ can load it but
>>>>> not
>>>>> the reverse). But there has never been a consensual agreement on that
>>>>> with
>>>>> the team. Years ago I proposed my own formatter. It's there as an
>>>>> attachment
>>>>> ofhttps://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions
>>>>> but
>>>>> for a reason no longer downloadable. So I added the one I use now:
>>>>>
>>>>> https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=776602
>>>>>
>>>>> <https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=7766027>
>>>>>
>>>>> To me (and others in above discussions, see notably Jacopo's point in
>>>>> the
>>>>> 1st convo) the most important thing is to not arbitrarily cut lines with
>>>>> automated formatter when creating fixing, improving or refactoring patch
>>>>> (it
>>>>> could makes sense in formatting patch, but do we really want that?).
>>>>>
>>>>> IMO Jacopo's point is the simplest solution to this problem: simply
>>>>> don't
>>>>> format when patching, or at least do that in specific patches but we
>>>>> then
>>>>> need to agree about lines lengths and IMO the longer the better (I use
>>>>> 180
>>>>> for code and comments, but of course rarely get so far)
>>>>>
>>>>> In OFBIZ-9877 Michael said
>>>>>       <<I would really like to have a coding style where we can rely on,
>>>>> that
>>>>> would make things much easier to maintain an even looking code. Maybe we
>>>>> should decide on a mandatory formatting and do a big reformatting
>>>>> session
>>>>> with no functional changes to have a common ground to continue with. But
>>>>> this is another issue.>>
>>>>> To be clear this is not top priority and not the subject of the current
>>>>> discussion
>>>>>
>>>>> About Formatting vs. refactoring:
>>>>> My point is: refactoring is not formatting and because refactoring is by
>>>>> itself already something which needs careful reviews, adding lines of
>>>>> formatting, mix 2 types of things. So, again, the subject of the current
>>>>> discussion, it's not functional vs not functional; but no formatting,
>>>>> especially lines cut, in commits but formatting commits.
>>>>>
>>>>> Another important point is the removing of trailing blanks. Why this one
>>>>> also? Because both lines cuts and trailing blanks removing are pure
>>>>> formatting things which when automated generated a lot of "false
>>>>> changes" in
>>>>> patches/commits and make their reviews harder. Most of the time other
>>>>> formatting points, like when and where to cut long method signature,
>>>>> EntityQuery.use(delegator).from() stuff, etc. should not be a problem.
>>>>> If
>>>>> you have ideas about that please share.
>>>>>
>>>>> So that's mostly it, and the question is: should we share an IDE
>>>>> auto-formatter? If so I propose to start from mine and refine, else
>>>>> what?
>>>>>
>>>>> I understand people not using an IDE will feel less concerned. But I
>>>>> guess
>>>>> they can also have an auto-formatter, it's maybe "just" harder to share
>>>>> :/
>>>>>
>>>>> And about the reasons and goals of this discussion, I see at least
>>>>>
>>>>> 1. easier review for patches (this is currently not a problem, people no
>>>>> longer do that) and commits (but specific formatting commits).
>>>>> 2. easier merging when coming from outside
>>>>> 3. please adds your...
>>>>>
>>>>> I propose to use a lazy consensus for this discussion, we don't want to
>>>>> vote
>>>>> about formatting ;)
>>>>>
>>>>> Thanks
>>>>>
>>>>> Jacques
>>>>>

[Jacques Le Roux]

I just changed one thing,  now OFBizJavaFormatter.xml is on svn at tools\wiki-files

Jacques


Le 21/12/2017 à 17:08, Jacques Le Roux a écrit :

> Yes it's mostly about lines split. I prefer 180 chars by line, but 120 would be fine with me,  I understand it's easier for laptop users.
>
> One thing I forgot to speak about is removing trailing blanks in patches/commits.
>
> So far we agreed to not do that. But Michael prefers to do it, and it seems apart me nobody spoke about that.
>
> I was initially doing so, but I got convinced to stop because it's  real pain for review. So I think we want to discuss that again also...
>
> For all the rest, it's sometimes a pain to backport or contribute patches when the formatting is not the same but by experience I know it's hard to
> convince people for an unique format.
>
> For instance when to use "if () {expression}" on one line or not (this is not Java convention, but sometimes useful), or where to split method
> signatures (120 chars is maybe long there), etc.
>
> The problem I crossed while reviewing Michael's bursts of patches was increased by "little" things like that, but yes mostly lines split and removed
> trailing blanks.
>
> On the other hand, as Michael advocated, this can be done in formatting patches (where nothing else is done but formatting).
>
> I think we should wrote that clearly in coding conventions when we will get a consensus.
>
> Jacques
>
>
> Le 21/12/2017 à 16:20, Taher Alkhateeb a écrit :
>> okay so I still am not quite sure what you're trying to suggest or
>> promote in this discussion. Do you encourage changing or updating the
>> coding conventions? if yes how? Do you wish to enforce or encourage
>> formatting tools? Are you only discussing line width? We can have a
>> discussion based on your feedback I guess.
>>
>> Either way, when it comes to line width, I would suggest that yeah
>> maybe 80 is too narrow for the modern age, but 180 could be too wide
>> and is an indicator of a code smell (if we're talking about Java). If
>> you can't say whatever you want to say in say 100 or 120 characters or
>> so then it might be indicative of a problematic code design.
>>
>> On Thu, Dec 21, 2017 at 6:09 PM, Jacques Le Roux
>> <[hidden email]>  wrote:
>>> I just added a link to my formatter at
>>> https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions
>>>
>>>
>>>
>>> Le 21/12/2017 à 15:55, Jacques Le Roux a écrit :
>>>> Actually it's not a [PROPOSAL] it's a [DISCUSSION]... kidding (but
>>>> nevertheless you can add your point 3 after mine ;))
>>>>
>>>> Seriously: after your request to open a discussion:
>>>> http://markmail.org/message/2bsp2fsbrdbd6dlb  I reported/wrote in this thread
>>>> some facts mostly based on our previous discussion with Michael at
>>>> OFBIZ-9877
>>>>
>>>> The proposal would be simple. I suggest all committers to use an
>>>> auto-formatter for Java code (for Groovy I don't know yet) and that it
>>>> should be, as much as possible, the same for all committers.
>>>>
>>>> So we need to define the rules, and I propose as a basis for this
>>>> discussion the formatter I use in Eclipse which is derived from the basic
>>>> Eclipse one for Java conventions. BTW I just updated it again (for Java 8 &
>>>> 9), mine was based on an old one.
>>>>
>>>> The main changes I introduced is a line length of 180, to avoid automated
>>>> lines split in patches (180 sounds reasonable and a good compromise to me
>>>> (below "-<setting id=" correspond to my changes).
>>>>
>>>>      -<setting id="org.eclipse.jdt.core.formatter.comment.line_length"
>>>> value="180"/>
>>>>      +<setting id="org.eclipse.jdt.core.formatter.comment.line_length"
>>>> value="80"/>
>>>>
>>>> Here are other minors changes I did, I have no strong opinions about them
>>>> (I did more in the past but finally simplified). Beware the changes are
>>>> reversed
>>>>
>>>>      -<setting
>>>> id="org.eclipse.jdt.core.formatter.keep_then_statement_on_same_line"
>>>> value="true"/>
>>>>      +<setting
>>>> id="org.eclipse.jdt.core.formatter.keep_then_statement_on_same_line"
>>>> value="false"/>
>>>>      -<setting id="org.eclipse.jdt.core.formatter.use_on_off_tags"
>>>> value="true"/>
>>>>      +<setting id="org.eclipse.jdt.core.formatter.use_on_off_tags"
>>>> value="false"/>
>>>>      -<setting
>>>> id="org.eclipse.jdt.core.formatter.keep_else_statement_on_same_line"
>>>> value="true"/>
>>>>      +<setting
>>>> id="org.eclipse.jdt.core.formatter.keep_else_statement_on_same_line"
>>>> value="false"/>
>>>>      -<setting
>>>> id="org.eclipse.jdt.core.formatter.indent_switchstatements_compare_to_switch"
>>>> value="true"/>
>>>>      +<setting
>>>> id="org.eclipse.jdt.core.formatter.indent_switchstatements_compare_to_switch"
>>>> value="false"/>
>>>>      -<setting
>>>> id="org.eclipse.jdt.core.formatter.keep_imple_if_on_one_line" value="true"/>
>>>>      +<setting
>>>> id="org.eclipse.jdt.core.formatter.keep_imple_if_on_one_line"
>>>> value="false"/>
>>>>      -<setting
>>>> id="org.eclipse.jdt.core.formatter.wrap_outer_expressions_when_nested"
>>>> value="true"/>
>>>>      +<setting
>>>> id="org.eclipse.jdt.core.formatter.wrap_outer_expressions_when_nested"
>>>> value="false"/>
>>>>
>>>> Of course, an auto-formatter is not a silver bullet and we need to accept
>>>> and define exceptions.
>>>>
>>>> For instance, one come instantly to my mind: when using
>>>>
>>>> EntityQuery.use(delegator).from()...
>>>>
>>>> It easier to read when sub-expressions are split by lines, same is true
>>>> for Java 8 Streams.
>>>>
>>>> I think we can also accept different ways of splitting method signatures
>>>> and other minor things that we can adjust if needed later (eg the 2nd block
>>>> of my changes)
>>>>
>>>> HTH
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Le 21/12/2017 à 12:53, Taher Alkhateeb a écrit :
>>>>> I'm not sure what is the proposal here
>>>>>
>>>>> On Tue, Dec 19, 2017 at 3:31 PM, Jacques Le Roux
>>>>> <[hidden email]>  wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Followinghttps://s.apache.org/9pTo  (OFBIZ-9877) and
>>>>>> http://markmail.org/message/2bsp2fsbrdbd6dlb  here is a discussion about
>>>>>> Formatting in OFBiz OOTB.
>>>>>>
>>>>>> Note we had already discussions in the past and these should be used as
>>>>>> references in this discussion
>>>>>> http://markmail.org/message/calbmwzd4nj32l4g
>>>>>> http://markmail.org/message/qx3base6tolxfcjf
>>>>>> http://markmail.org/message/t2am3t6eev6zk5bj
>>>>>>
>>>>>> I don't want to repeat myself too much but for the use of readers here,
>>>>>> here
>>>>>> are some points I think are important.
>>>>>>
>>>>>> Long in the past I suggested to share and, use as much as possible, the
>>>>>> same
>>>>>> formatter (it must come from Eclipse because IntelliJ can load it but
>>>>>> not
>>>>>> the reverse). But there has never been a consensual agreement on that
>>>>>> with
>>>>>> the team. Years ago I proposed my own formatter. It's there as an
>>>>>> attachment
>>>>>> ofhttps://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions
>>>>>> but
>>>>>> for a reason no longer downloadable. So I added the one I use now:
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=776602
>>>>>>
>>>>>> <https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=7766027>
>>>>>>
>>>>>> To me (and others in above discussions, see notably Jacopo's point in
>>>>>> the
>>>>>> 1st convo) the most important thing is to not arbitrarily cut lines with
>>>>>> automated formatter when creating fixing, improving or refactoring patch
>>>>>> (it
>>>>>> could makes sense in formatting patch, but do we really want that?).
>>>>>>
>>>>>> IMO Jacopo's point is the simplest solution to this problem: simply
>>>>>> don't
>>>>>> format when patching, or at least do that in specific patches but we
>>>>>> then
>>>>>> need to agree about lines lengths and IMO the longer the better (I use
>>>>>> 180
>>>>>> for code and comments, but of course rarely get so far)
>>>>>>
>>>>>> In OFBIZ-9877 Michael said
>>>>>>       <<I would really like to have a coding style where we can rely on,
>>>>>> that
>>>>>> would make things much easier to maintain an even looking code. Maybe we
>>>>>> should decide on a mandatory formatting and do a big reformatting
>>>>>> session
>>>>>> with no functional changes to have a common ground to continue with. But
>>>>>> this is another issue.>>
>>>>>> To be clear this is not top priority and not the subject of the current
>>>>>> discussion
>>>>>>
>>>>>> About Formatting vs. refactoring:
>>>>>> My point is: refactoring is not formatting and because refactoring is by
>>>>>> itself already something which needs careful reviews, adding lines of
>>>>>> formatting, mix 2 types of things. So, again, the subject of the current
>>>>>> discussion, it's not functional vs not functional; but no formatting,
>>>>>> especially lines cut, in commits but formatting commits.
>>>>>>
>>>>>> Another important point is the removing of trailing blanks. Why this one
>>>>>> also? Because both lines cuts and trailing blanks removing are pure
>>>>>> formatting things which when automated generated a lot of "false
>>>>>> changes" in
>>>>>> patches/commits and make their reviews harder. Most of the time other
>>>>>> formatting points, like when and where to cut long method signature,
>>>>>> EntityQuery.use(delegator).from() stuff, etc. should not be a problem.
>>>>>> If
>>>>>> you have ideas about that please share.
>>>>>>
>>>>>> So that's mostly it, and the question is: should we share an IDE
>>>>>> auto-formatter? If so I propose to start from mine and refine, else
>>>>>> what?
>>>>>>
>>>>>> I understand people not using an IDE will feel less concerned. But I
>>>>>> guess
>>>>>> they can also have an auto-formatter, it's maybe "just" harder to share
>>>>>> :/
>>>>>>
>>>>>> And about the reasons and goals of this discussion, I see at least
>>>>>>
>>>>>> 1. easier review for patches (this is currently not a problem, people no
>>>>>> longer do that) and commits (but specific formatting commits).
>>>>>> 2. easier merging when coming from outside
>>>>>> 3. please adds your...
>>>>>>
>>>>>> I propose to use a lazy consensus for this discussion, we don't want to
>>>>>> vote
>>>>>> about formatting ;)
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jacques
>>>>>>
>
>