[
https://issues.apache.org/jira/browse/OFBIZ-9877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16293749#comment-16293749 ]
Michael Brohl commented on OFBIZ-9877:
--------------------------------------
Hi Jacques,
I fully understand your concerns and we don't want to introduce too much formatting changes. From what I understand, the team has used a formatting style based on a formatter file for Eclipse, like I do. I cannot find the download link for it right now, but the understanding was that this is the recommended style. I have it in Eclipse for years.
In [1] is stated that we use the Sun coding standards, which seems not to be the case. For example, they recommend a line width of 80 characters (which is wayy too short for my taste). maybe we should get rid of this part in the wiki or do some updates.
I assume that there is no real coding convention used by EVERY developer or at least by EVERY committer so you will always have different formatting styles. You can really see the different styles in the code base. Some people do not seem to use formatting at all.
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.
Formating vs. refactoring: we have provided the contents of this series of patches for refactoring, see OFBIZ-9836, including some formatting changes (like {} around if/else statements). There should be no functional changes with the exception of multi-catches. The functional changes were in the FindBugs patches.
There was no objection against it so we started to work on it this way.
So before I do the commit work for the OFBIZ-9836 patches (which was planned for today, better say: NOW), we have to decide how to proceed. There is much work done and a i have not the capacity to change all the formatting which might be done in the patches.
Like the FindBugs, I would like to get this package of changes into the coming release branch. Our team wants to focus on functional enhancements in the next step and close this chapter shortly.
I see the following possible moves:
1. commit the patches with the formatting like it is done there and accept some "noise".
2. we quickly decide on a formatting style or mainly line length and I'll try to reformat while I am committing. I assume that this will introduce other reformattings in other code parts because there is so much mixed style. Not sure if this is better.
3. I do nothing, say: do not commit. This would be really sad for all the work done. We've invested a lot in this effort.
However we decide, we should take care of getting some binding coding conventions together to avoid confusion in the future.
[1]
https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions> [Refactoring] Package org.apache.ofbiz.accounting.tax
> -----------------------------------------------------
>
> Key: OFBIZ-9877
> URL:
https://issues.apache.org/jira/browse/OFBIZ-9877> Project: OFBiz
> Issue Type: Sub-task
> Components: accounting
> Affects Versions: Trunk
> Reporter: Julian Leichert
> Assignee: Michael Brohl
> Priority: Minor
> Fix For: Upcoming Release
>
> Attachments: OFBIZ-9877_org.apache.ofbiz.accounting.tax.TaxAuthorityServices_refactoring.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
Locked
