Mandatory conventions

1. Headers

   Look at the Headers document for more information.

2. Indentations

   4 spaces. NO tabs.

3. Javadoc

   All API interfaces and classes must be fully documented through javadocs comments at interface/class, method and package level.

   When you inherit or extend from another interface or class which is already documented, and implement or rewrite one of the parent methods, don't write any javadoc comments, as they are also inherited since java 1.4.

4. Brackets

   All brackets should begin at the end of the line that begins the statement, and end on a new line indented to the beginning of the statement. Example:

   AVOID:

   public class MyClass 
   {
   
       public void someMethod() 
       {
           if (...) { // Do something }
   }
   }
   

   RIGHT:

   public class MyClass {
   
       public void someMethod() {
           if (...) {
             // Do something
           }
       }
   }
   

   Brackets are mandatory even for single line statements:

   if (expression)       // AVOID!
       // some code
   
   if (expression) {     // RIGHT
       // some code
   }
   

5. 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");
   

6. Class variables

   Class variables should not have any prefix or suffix related to its data type or scope. Example:

   String nameString;   // AVOID!
   
   String name;         // RIGHT
   

7. Parameter names

   Method parameters should be prefixed by "the" for differentiating them from inner variables, when there is an inner variable with the same name or use. For example:

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

8. Line length

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

9. Versioning

   All .java files should have a @version tag like the one below into the class javadoc comment:

   @version $Id$
   

10. Logging

    Do not use System.out to log. Instead, use the SLF4J logging API. For example:

    private static final Logger LOG = 
        LoggerFactory.getLogger(MyClass.class);
    
    public void someMethod() {
        LOG.debug("some debug text");
    }
    

    For more information on SLF4J usage, you can read the Logging document.

11. 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.
    • 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.
    • Rule 5: Create one parent Exception for each API library, so methods of the API that throw any exception use that parent exception or one of the child ones.
    • Rule 6: If you have an exception or an error which can't be handled or resolved by code, throw or rethrow a BaseRuntimeException subclass.

    An example:

    public void getTestClass() {
        try {
            Class responseClass =
                Class.forName("some.package.MyClass");
        } catch (ClassNotFoundException cnfe) {
            String message = "Cannot instantiate test class";
            LOG.error(message, ex);
            throw new ChainedRuntimeException(message, e);
        }
    }
    

12. Qualified imports

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

    // AVOID!
    import java.util.*;
    import java.net.*;
    
    // RIGHT
    import java.util.Date;
    import java.net.HttpURLConnection;
    

13. Use interfaces in the declaration of methods and variables.

    By example, if you need a variable x that is a list, declare it as List instead an ArrayList:

    // AVOID!
    ArrayList x = new ArrayList();
    HashMap y = new HashMap();
    
    public HashMap create(ArrayList keys, ArrarList values) {
        ...
    }
    
    // RIGHT
    List x = new ArrayList();
    Map y = new HashMap();
    
    public Map create(List keys, List values) {
        ...
    }
    

14. API packages

    Usually, API interfaces and classes will belong to the library's main root package. If you create subpackages, use them to group by functionality, not by type.

15. How to name packages

    All packages must begin with org.gvsig.

    For more information on this convention, you can read the How to name packages document.

Advised conventions

1. How to name interfaces and classes

Use of prefixes and suffixes in general

The use of prefixes and/or suffixes in the names of classes and interfaces is usually a means of providing information about their nature and/or task. For example they can be used to denote a pattern, or a role within a pattern (eg the suffix Factory). At other times, it is necessary to use them if the appropriate name has already been assigned. This is the case of the prefixes and suffixes that are described below.

As a general rule:

• Only use a prefix or suffix when you can't use the simple name (usually because it is being used by another class or interface).

Using the prefix "Abstract"

• Only to be used for classes, not interfaces.
• The class must be abstract and implement an interface.
• Only used when the interface being implemented has the same name.

Example:

public interface List {}
public abstract class AbstractList extends AbstractCollection implements List {}

Using the prefix "I"

• It is recommended that this prefix not be used.

  Typically, the interfaces are the visible part of a component model. They usually represent entities and concepts from the business or domain and therefore it is recommended that the same names be used as in the business.

Using the prefix "Default"

• Can't be an abstract class.
• A default implementation of an interface or an abstract class.
• The implementation should be sufficient, but not necessarily complete.
• There may be alternative implementations of this class.

Example:

public interface ListModel {}
public abstract class AbstractListModel implements ListModel, Serializable {}
public class DefaultListModel extends AbstractListModel {}

Using the prefix "Base"

• Not an abstract class.
• Provides a "base" implementation of an interface or an abstract class.
• The class can be instantiated and not used any more, but is designed for the user of the extended component.
• Do not use this prefix if no interface or parent abstract class exists.

Example:

public abstract class StreamRequestHandler {}
public class BaseHTTPRequestHandler extends StreamRequestHandler {}

Using the suffix "Impl"

• It is a class instance and therefore can't be abstract
• It is a complete implementation of an interface or abstract class, generally referred to as the class without the "impl".
• Other classes should not be extended from it.
• Do not use this suffix unless the class name conflicts with the name of the interface or abstract class being implemented.
• If this is the default implementation of part of the API and does not conflict with other parts of the project, the prefix Default is preferred.

Example:

public interface Plane {}
public abstract class AbstractPlane implements Plane {}
 
// Both are correct (but not equal)
public class PlaneImpl implements Plane {} 
public class PlaneImpl extends AbstractPlane {}