Coding Conventions

Last update : July 29 2002
Doc for : v1.4b1

About
  • What is Cactus ?
  • News
  • Changes
  • Features/Status
  • Goals
  • Roadmap/Todo
  • Contributors
  • Contributing
  • Cactus Users
  • Tested on ...
  • License


  • Downloads
  • Downloads


  • Documentation
  • How it works ?
  • Getting Started
  • Mock vs Container
  • Javadocs
  • FAQ


  • Howto Guides
  • Classpath Howto
  • Config Howto
  • Migration Howto
  • TestCase Howto
  • Runner Howto
  • Security Howto
  • Ant Howto
  • HttpUnit Howto
  • Sample Howto
  • EJB Howto
  • IDE Howto
  • Tomcat Howto
  • JUnitEE Howto


  • Support
  • Bug database
  • Mailing list


  • Misc.
  • Why the name ?
  • Logo Challenge
  • Resources
  • Test Coverage
  • Stats


  • Developers
  • CVS
  • Coding Conventions
  • Build results
  • Release Checklist


  • Forewords

    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.

    Note If you commit code that does not follow these conventions and you are caught, you are responsible for also fixing your own code.

    Below is a list of coding conventions that are specific to Cactus, everything else not specificially mentioned here should follow the official Sun Java Coding Conventions.


    How to apply ?

    Having coding conventions is nice but having a way to ensure they are applied is even better ... :-)

    The Cactus Ant build file has a checkstyle target which performs coding conventions using the Checkstyle tool. Drop the Checkstyle jars in your ANT_HOME/lib, go in the build/ directory and type ant checkstyle.

    Please run this target before committing any code.


    Cactus specific coding conventions

    1. Brackets

    For class and method declaration, brackets should begin and end on a new line. Example :

    public class SomeClass
    {
        public void someMethod()
        {
        }
    }
    

    Brackets for blocks of code inside methods should begin and end on the same line (this applies to if, for, while, try/catch, ...). Example :

    public void someMethod()
    {
        if (expression) {
        } else if (other_expression) {
        }
    
        try {
        } catch (Exception e) {
        }
    }
    

    Brackets are mandatory even for single line statements !

    // Incorrect
    if (expression)
        // some code
    
    // Correct
    if (expression) {
        // some code
    }
    

    2. Blank Spaces

    keywords followed by a parenthesis should be separated by a space. Example :

    while (true) {
        // some code
    }
    

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

    a += c + d;
    a = (a + b) / (c * d);
    
    while (d++ = s++) {
        n++;
    }
    
    printSize("size is " + foo + "\n");
    

    3. Indentations

    4 spaces. NO tabs. 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.


    4. Comments

    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.

    Also add code comments when you think it's necessary (like assumptions), especially when the code is not obvious.


    5. License

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


    6. Author references

    If you contribute to a file (code or documentation), add yourself to the top of the file (below the existing authors). For java files the preferred Javadoc format is:

    @author <a href="mailto:user@domain.com">John Doe</a>
    

    7. Class variables

    Class variables should not have any prefix and must be referenced using the this object. Example :

    public class SomeClass
    {
        private String someString;
    [...]
        public void someMethod()
        {
            logger.debug("Value = " + this.someString);
        }
    }
    

    8. Parameter names

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

    public void someMethod(String theClassName)
    {
        String className; // inner variable
    }
    

    9. Line length

    Avoid lines longer than 80 characters for Code, comments, ...


    10. Versioning

    All .java files should have a @version tag like the one below.

    @version $Id: coding_conventions.xml,v 1.1 2002/03/10 14:10:25 vmassol Exp $
    

    11. Logging

    Do not use System.out to log. Instead, use the Cactus logging classes which are a facade to Log4j. Use the name of your class as the Log4j Category. For example :

    private static Log logger =
    		LogService.getInstance().getLog(MyClass.class.getName());
    
    public void someMethod()
    {
    		logger.debug("some debug text");
    }
    

    Note As of Cactus 1.3, LogAspect autmatically logs all method entries and exits.


    12. Exception handling

    Managing exceptions correctly requires experience. This is not supposed to be a guide on managing exceptions, simply a few best practices.

    • Rule 1 : 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).
    • Rule 2 : It is important not to loose the stack trace which contains important information. Use chained exceptions for that. Cactus provides a ChainedRuntimeException for chaining runtime exceptions.
    • Rule 3 : Always log the exception at the higher level (ie. where it is handled and not rethrown).
    • Rule 4 : Try to avoid catching Throwable or Exception and catch specific exceptions instead.

    An example :

    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);
        }
    }
    

    13. Qualified imports

    All import statements should containing the full class name of classes to import and should not use the "*" notation :

    An example :

    // Correct
    import java.util.Date;
    import java.net.HttpURLConnection;
    
    // Not correct
    import java.util.*;
    import java.net.*;
    




    Copyright © 2000-2002 The Apache Software Foundation. All Rights Reserved.