Code conventions

The rules are set in two parts, style and programming practices.

About style, are listed only rules that differ from [1] or are unspecified.

Ref.:

Style

Comments

Package comment ([2])

Each package must have its own package-level doc comment source file.

The minimal template is:

<html>
<body>

Provides interfaces and classes for IoC capable properties that resolve and obtain their values at run-time.

</body>
</html>

Usually, the comment will have some links:

<html>
<body>

Provides classes and interfaces for the mail queue.

<h2>Related Documentation</h2>

For overviews, tutorials, examples, guides, and documentation, please see:
<ul>
	<li><a href="http://rifers.org/wiki/display/RIFE/Mail+queue">[Wiki] Mail queue</a></li>
</ul>

</body>
</html>

Class file comment ([1], chap. 3)

Each class file must start with:

/*
 * Copyright 2001-2006 Geert Bevin <gbevin[remove] at uwyn dot com>
 * Distributed under the terms of either:
 * - the common development and distribution license (CDDL), v1.0; or
 * - the GNU Lesser General Public License, v2.1 or later
 * $Id$
 */

If there are many contributors, add them after the first one:

/*
 * Copyright 2001-2006 Geert Bevin <gbevin[remove] at uwyn dot com>; and
 * Bertrand Durand <bdurand[remove] at icietpartout dot com>
[...]

Import statements ([1], chap. 3)

The usual order is first the non JDK imports and then the JDK ones. Also, first the wildcart imports and then the single ones. As soon as there are 5 single ones of the same package, they become a wildcart import.

Indentation ([1], chap. 4)

Tab must be set every four characters.

Avoid writing parameters of a method call on many lines, no matter the line length.

Lines have no length limits; they can be longer than 80 or 120 characters.

When an expression will not fit on a single line, break it after an operator.

Statement ([1], chap. 7)

Blank space ([1], chap. 8)

Avoid blank line before the final brace of a class.

Blank spaces should never separate unary operators, including the logical NOT operator "!".

Avoid white space after an opening parenthesis or before a closing parenthesis.

Naming Conventions ([1], chap. 9)

Local variables should always be lower case, with each part being seperated by an underscore, as in:

public void yourMethod()
{
    String this_is_my_string = "value";
}

Method parameters should be lower cased, with each part being capitalized for clear seperation, as in:

public void yourMethod(String theMethodParameter)
{
    ...
}

For member variables (instance variables), prefix the name with 'm', as in:

private Object mParameter = null;
private String mName = null;

For static class variables, prefix the name with 's', as in:

public static Object sParameter = null;

For final static class variables, use all upper-cased names, as in:

public final static Object PARAMETER = null;

Miscellaneous Practices

Avoid IDE features, as //$NON-NLS-xxx$ with Eclipse

For RIFE properties, use plausible name for real properties as much as possible. When injected into the element instance, when the setters are present they will look nicer.

Programming practices

In method parameters, reduce boolean flags as little as possible since without reading the JavaDocs, it's impossible to know what the method call does once it's written.

In conditional expressions against constants, put the constant before the variable. The reason for this is that if you accidently write one equals sign instead of two, the compiler will complain.

if (null == parameter ||
    123 == value)
{
   ...
}

In conditional expressions with literal and the equals method, put the literal before the variable. The reason for this is to avoid NullPointerException as much as possible.

if ("sometext".equals(text))
{
   ...
}

Document generated by Confluence on Oct 19, 2010 14:56