I'm not sure what is the proposal here
On Tue, Dec 19, 2017 at 3:31 PM, Jacques Le Roux <[email protected]> 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 >
