Derby
  1. Derby
  2. DERBY-1363

Derby should publish a well defined coding convention per the db project guidlines

    Details

    • Type: Task Task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Web Site
    • Labels:
      None
    • Urgency:
      Normal

      Description

      The DB project guidlines dictate that we should have a well defined convention for coding standards.
      http://db.apache.org/source.html says

      "Java Language source code in the repository must be written in conformance to the " Code Conventions for the Java Programming Language as published by Sun, or in conformance with another well-defined convention specified by the subproject. See the FAQ page for links to subproject conventions."

      We should publish at least a well defined convention for new code in order to comply with the db project guidlines.

      Discussion for whether to reformat or not once that is decided is under discussion in the thread:
      http://www.nabble.com/Code+formatting+debate%2C+confusion+and+wasted+time+%2C+Has+it+gone+on+long+enough--t1710825.html

      but at least the coding standards should be defined.

        Activity

        Hide
        Andrew McIntyre added a comment -

        Unsetting Fix Version for unassigned issues.

        Show
        Andrew McIntyre added a comment - Unsetting Fix Version for unassigned issues.
        Hide
        Rick Hillegas added a comment -

        Move to 10.2.3.0.

        Show
        Rick Hillegas added a comment - Move to 10.2.3.0.
        Hide
        Rick Hillegas added a comment -

        Moving to 10.2.2.0.

        Show
        Rick Hillegas added a comment - Moving to 10.2.2.0.
        Hide
        Kathey Marsden added a comment -

        Putting handling of existing code aside, I would like to propose we adopt the client code format moving forward. My reasons have nothing to do with love of that actual format but are as follows:

        1) We need a coding convention to be in compliance with the db project guidlines.
        2) A large portion of the code is already in that format, Jeremy made a pass after contribution.
        3) This issue has wasted huge amounts of time for the Derby community and burnt virtually every new developer.
        4) The format if as Jeremy described should be fairly easy to configure in most IDE's.

        Here is Jeremy's description of that format.
        http://www.nabble.com/Re%3A-Reformat-client-code--p9229.html
        It needs to be researched and documented and perhaps items that are already on the checklist like 80 characters per line added.

        Jeremy sure was right about the bikeshed discussion [1] and very wise to just pull the band-aid off quick despite all the whining by me and others. Please before you consider raising serious objections to this consider all it has and will cost the project if we don't come to consensus on this.

        If there are no objections, we can then take the next step to document the format and next figure out how to get there for the full code base, but if we can get past this step I think we will have made great progress on this issue.

        Kathey

        http://www.unixguide.net/freebsd/faq/16.19.shtml

        Show
        Kathey Marsden added a comment - Putting handling of existing code aside, I would like to propose we adopt the client code format moving forward. My reasons have nothing to do with love of that actual format but are as follows: 1) We need a coding convention to be in compliance with the db project guidlines. 2) A large portion of the code is already in that format, Jeremy made a pass after contribution. 3) This issue has wasted huge amounts of time for the Derby community and burnt virtually every new developer. 4) The format if as Jeremy described should be fairly easy to configure in most IDE's. Here is Jeremy's description of that format. http://www.nabble.com/Re%3A-Reformat-client-code--p9229.html It needs to be researched and documented and perhaps items that are already on the checklist like 80 characters per line added. Jeremy sure was right about the bikeshed discussion [1] and very wise to just pull the band-aid off quick despite all the whining by me and others. Please before you consider raising serious objections to this consider all it has and will cost the project if we don't come to consensus on this. If there are no objections, we can then take the next step to document the format and next figure out how to get there for the full code base, but if we can get past this step I think we will have made great progress on this issue. Kathey http://www.unixguide.net/freebsd/faq/16.19.shtml
        Hide
        Kathey Marsden added a comment -

        Setting this to fix version 10.2 as a high value fix candidate. This issue has hit virtually every new developer that has joined the project and already cost many developer and reviewer hours. Francois calls it an infection and I think this is true. As we get more and more developers in just wanting to fix their bug and move on it will become more and more of an issue, not to mention that our current state puts is in violation of the db project guidelines.

        My vote, document and adopt the client code format moving forward, only because a large chunk of code is that way already and we get rid of the tabs, but of course I would defer to the brave soul willing to take this on.

        Show
        Kathey Marsden added a comment - Setting this to fix version 10.2 as a high value fix candidate. This issue has hit virtually every new developer that has joined the project and already cost many developer and reviewer hours. Francois calls it an infection and I think this is true. As we get more and more developers in just wanting to fix their bug and move on it will become more and more of an issue, not to mention that our current state puts is in violation of the db project guidelines. My vote, document and adopt the client code format moving forward, only because a large chunk of code is that way already and we get rid of the tabs, but of course I would defer to the brave soul willing to take this on.

          People

          • Assignee:
            Unassigned
            Reporter:
            Kathey Marsden
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development