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
