<?xml version="1.0"?>

<!--
 * ========================================================================
 * 
 * Copyright 2001-2004 The Apache Software Foundation.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 * 
 *   http://www.apache.org/licenses/LICENSE-2.0
 * 
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 * 
 * ========================================================================
-->

<document id="coding_conventions">

  <properties>
    <title>Coding Conventions</title>
  </properties>

  <body>

    <section title="Forewords">

      <p>
        This document describes a list of coding conventions that are
        required for code submissions to the project. By default, the coding
        conventions for most Open Source Projects should follow the existing
        coding conventions in the code that you are working on. For example,
        if the bracket is on the same line as the if statement, then you
        should write all your code to have that convention.
      </p>
      <note>
        <strong>If you commit code that does not follow these conventions and
        you are caught, you are responsible for also fixing your own code.
        </strong>
      </note>
      <p>
         Below is a list of coding conventions that are specific to Cactus,
         everything else not specificially mentioned here should follow the
         official <link href="ext:sun_coding_conventions">Sun Java Coding 
         Conventions</link>.
      </p>

    </section>

    <section title="How to apply?">

      <p>
        Having coding conventions is nice but having a way to ensure they are
        applied is even better ... :-)
      </p>
      <p>
        The Cactus Ant build file has a <code>checkstyle</code> target which
        performs coding conventions using the
        <link href="ext:checkstyle">Checkstyle</link> tool. Drop the
        Checkstyle jars in your <code>ANT_HOME/lib</code>, go in the
        <code>build/</code> directory and type <code>ant checkstyle</code>.
      </p>
      <p>
        Please run this target before committing any code.
      </p>

    </section>

    <section title="Cactus specific coding conventions">

      <section title="1. Brackets">

        <p>
          All brackets should begin and end on a <strong>new</strong> line. Example:
        </p>

<source><![CDATA[
public class SomeClass
{
    public void someMethod()
    {
        if (...)
        {
        }
    }
}
]]></source>

        <p>
          <strong>Brackets are mandatory even for single line statements !
          </strong>
        </p>

<source><![CDATA[
// Incorrect
if (expression)
    // some code

// Correct
if (expression)
{
    // some code
}
]]></source>

      </section>

      <section title="2. Blank Spaces">

        <p>
           keywords followed by a parenthesis should be separated by a space.
           Example:
        </p>

<source><![CDATA[
while (true)
{
    // some code
}
]]></source>

        <p>
          Blank space should appear after commas in argument lists. Binary
          operators should be separated from their operands by spaces:
        </p>

<source><![CDATA[
a += c + d;
a = (a + b) / (c * d);

while (d++ = s++)
{
    n++;
}

printSize("size is " + foo + "\n");
]]></source>

      </section>

      <section title="3. Indentations">

        <p>
          <strong>4 spaces. NO tabs</strong>. Period. We understand that a lot
          of you like to
          use tabs, but the fact of the matter is that in a distributed
          development environment, when the cvs commit messages get sent to a
          mailing list, they are almost impossible to read if you use tabs.
        </p>

      </section>

      <section title="4. Comments">

        <p>
          Javadoc SHOULD exist on all your class members (methods + class
          variables), including the private ones. Also, if you are working on
          existing code and there currently isn't a javadoc for that
          method/class/variable or whatever, then you should contribute and
          add it. This will improve the project as a whole.
        </p>
        <p>
          Also add code comments when you think it's necessary (like
          assumptions), especially when the code is not obvious.
        </p>

      </section>

      <section title="5. License">

        <p>
          The Jakarta Apache/Cactus License MUST be placed at the top of each
          and every file.
        </p>

      </section>

      <section title="6. Author references">

        <p>
          Do not put <code>@author</code> tags in source code. We are following
          the Apache board recommendation. This view is 
          <a href="ext:apache_no_author_tags">summarized</a> nicely
          by Dirk-Willem Van Gullick, president of the ASF.
        </p>
        <p>
          However you are very much encouraged to edit the 
          <code>contributors.xml</code> file located in 
          <code>jakarta-cactus/documentation/docs/xdocs/participating/</code>
          which lists contributors' participation.
        </p>

      </section>

      <section title="7. Class variables">

        <p>
          Class variables should not have any prefix and <strong>must</strong>
          be referenced using the <code>this</code> object. Example:
        </p>

<source><![CDATA[
public class SomeClass
{
    private String someString;
[...]
    public void someMethod()
    {
        logger.debug("Value = " + this.someString);
    }
}
]]></source>

      </section>

      <section title="8. Parameter names">

        <p>
          Method parameters should be prefixed by "<code>the</code>" (for
          differentiating them from inner variables). For example:
        </p>

<source><![CDATA[
public void someMethod(String theClassName)
{
    String className; // inner variable
}
]]></source>

      </section>

      <section title="9. Line length">

        <p>
          Avoid lines longer than 80 characters for Code, comments, ...
        </p>

      </section>

      <section title="10. Versioning">

        <p>
          All .java files should have a <code>@version</code> tag like the one
          below.
        </p>

<source><![CDATA[
@version $Id: coding_conventions.xml 238846 2004-03-13 14:40:48Z vmassol $
]]></source>

      </section>

      <section title="11. Logging">

        <p>
          Do <strong>not</strong> use <code>System.out</code> to log. Instead,
          use the <code>commons-logging</code> Logging system. For example:
        </p>

<source><![CDATA[
private static final Log LOGGER = 
    LogFactory.getLog(MyClass.class);

public void someMethod()
{
		LOGGER.debug("some debug text");
}
]]></source>

        <note>
          As of Cactus 1.3, LogAspect autmatically logs all method entries and
          exits.
        </note>
      </section>

      <section title="12. Exception handling">

        <p>
          Managing exceptions correctly requires experience. This is not
          supposed to be a guide on managing exceptions, simply a few best
          practices.
        </p>
        <ul>
          <li>
            <strong>Rule 1</strong>: Try to catch exceptions as much as
            possible and rethrow higher level exceptions (meaning hiding the
            low level detailed and putting a message that is more related to
            the function of your code).
          </li>
          <li>
            <strong>Rule 2</strong>: It is important not to loose the stack
            trace which contains important information. Use chained exceptions
            for that. Cactus provides a <code>ChainedRuntimeException</code>
            for chaining runtime exceptions.
          </li>
          <li>
            <strong>Rule 3</strong>: Always log the exception at the higher
            level (ie. where it is handled and not rethrown).
          </li>
          <li>
            <strong>Rule 4</strong>: Try to avoid catching
            <code>Throwable</code> or <code>Exception</code> and catch
            specific exceptions instead.
          </li>
        </ul>
        <p>
          An example:
        </p>

<source><![CDATA[
public void getTestClass()
{
    try
    {
        Class responseClass =
            Class.forName("some.package.MyClass");
    } 
    catch (ClassNotFoundException cnfe)
    {
        String message = "Cannot instantiate test class";
        logger.error(message);
        throw new ChainedRuntimeException(message, e);
    }
}
]]></source>

      </section>

      <section title="13. Qualified imports">

        <p>
          All <code>import</code> statements should containing the full class
          name of classes to import and should not use the <code>"*"</code>
          notation:
        </p>
        <p>
          An example:
        </p>

<source><![CDATA[
// Correct
import java.util.Date;
import java.net.HttpURLConnection;

// Not correct
import java.util.*;
import java.net.*;
]]></source>


      </section>

    </section>

  </body>
</document>
