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.
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.
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.
All brackets should begin and end on a new line. Example:
public class SomeClass { public void someMethod() { if (...) { } } }
Brackets are mandatory even for single line statements !
// Incorrect if (expression) // some code // Correct if (expression) { // some code }
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");
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.
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.
The Jakarta Apache/Cactus License MUST be placed at the top of each and every file.
Do not put @author
tags in source code. We are following
the Apache board recommendation. This view is
summarized nicely
by Dirk-Willem Van Gullick, president of the ASF.
However you are very much encouraged to edit the
contributors.xml
file located in
jakarta-cactus/documentation/docs/xdocs/participating/
which lists contributors' participation.
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); } }
Method parameters should be prefixed by "the
" (for
differentiating them from inner variables). For example:
public void someMethod(String theClassName) { String className; // inner variable }
Avoid lines longer than 80 characters for Code, comments, ...
All .java files should have a @version
tag like the one
below.
@version $Id: coding_conventions.xml 238846 2004-03-13 14:40:48Z vmassol $
Do not use System.out
to log. Instead,
use the commons-logging
Logging system. For example:
private static final Log LOGGER = LogFactory.getLog(MyClass.class); public void someMethod() { LOGGER.debug("some debug text"); }
Managing exceptions correctly requires experience. This is not supposed to be a guide on managing exceptions, simply a few best practices.
ChainedRuntimeException
for chaining runtime exceptions.
Throwable
or Exception
and catch
specific exceptions instead.
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); } }
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.*;