This page last changed on Aug 22, 2006 by holger.

This page contains CheckStyle rules to be applied to any code committed to the Mule project.

Coding Style

Having a constant coding style accross the whole project  has proved
to be a good thing for developer productivity, clean code, less bugs
and to avoid unexpected behaviours. Right now Mule is missing this kind of
knowledge.

Tools

We take, as a reference tool, Checkstyle and you will find relevance
of the notes that follow in its documentation

Checkstyle also has a maven plugin which could be dropped in the
standard build cycle quite easily

Conventions

JavaDoc comments

The JavadocType, JavadocMethod accompained with JavadocStyle should
be mandatory, PackageHtml should be highly advised.
       

<!-- http://checkstyle.sf.net/config_javadoc.html -->
<module name="JavadocMethod"/>
<module name="JavadocType"/>
<module name="JavadocVariable"/>

Naming conventions

All the standard naming convention should be enforced, maybe just the
AbstractClassName (which enforce Abstract prefix or Factory suffix)
and ConstantName (which enforce all CAPS) should be excluded, even if
the latter is quite useful on a wide project like Mule is.

<!-- http://checkstyle.sf.net/config_naming.html -->
<module name="LocalFinalVariableName"/>
<module name="LocalVariableName"/>
<module name="MethodName"/>
<module name="PackageName"/>
<module name="ParameterName"/>
<module name="StaticVariableName"/>
<module name="TypeName"/>
<module name="MemberName"/>
<!-- <module name="ConstantName"/> -->

Imports

We should AvoidStarImport even if it makes java files longer is a source
of good information and provide clear statements of what class are really
used.
IllegalImport, RedundantImport and UnusedImports should be obvious choice.

<!-- http://checkstyle.sf.net/config_import.html -->
<module name="AvoidStarImport"/>
<module name="IllegalImport"/>
<module name="RedundantImport"/>
<module name="UnusedImports"/>

Size

Just some checks for the sake of sanity files longer the 2000 lines and
methods with more then 7 parameters makes the code not so easy to read.
I usually use an high monitor resolution so I'm not addicted to the
MethodLenght check but others would like to add it.    

<!-- http://checkstyle.sf.net/config_sizes.html -->
<module name="FileLength"/>
<module name="ParameterNumber"/>

Whitespace

I think this are just part of the default Sun coding convention.
We would set tabWidth propertiy to 4 (actually I'm not so sure here)

<!-- http://checkstyle.sf.net/config_whitespace.html -->
<module name="EmptyForIteratorPad"/>
<module name="NoWhitespaceAfter"/>
<module name="NoWhitespaceBefore"/>
<module name="OperatorWrap"/>
<module name="TabCharacter"/>
<module name="WhitespaceAfter"/>
<module name="WhitespaceAround"/>

Modifier order

Follow the order of the Java Language specification and avoid redudant
modifier on interface and annotations

       

<!-- http://checkstyle.sf.net/config_modifiers.html -->
<module name="ModifierOrder"/>
<module name="RedundantModifier"/>

Block checks

The braces should be around every block just like there should be no
empty blocks, left curly should go on a new line and right curly alone
so we go with:

if ()
{ } else { }

<\!-\- [http://checkstyle.sf.net/config_blocks.html] \-->
<module name="AvoidNestedBlocks"/>
<module name="EmptyBlock"/>
<module name="NeedBraces"/>
<module name="LeftCurly">
 <property name="option" value="nl"/>
</module>
<module name="RightCurly">
 <property name="option" value="alone"/>
</module>

I don't agree with this one, I think the placement of curly brackets is a matter of personal preference and either way can produce nice, readable code if the programmer uses a little aesthetic sense.
- Travis

Coding

This should be fairly usual even if I think that sometimes InlineConditionals
are not that bad.
More on this should be stated.

<\!-\- [http://checkstyle.sf.net/config_coding.html] \-->
<module name="AvoidInlineConditionals"/>
<module name="DoubleCheckedLocking"/>
<module name="EmptyStatement"/>
<module name="EqualsHashCode"/>
<module name="HiddenField"/>
<module name="IllegalInstantiation"/>
<module name="InnerAssignment"/>
<module name="MagicNumber"/>
<module name="MissingSwitchDefault"/>
<module name="RedundantThrows"/>
<module name="SimplifyBooleanExpression"/>
<module name="SimplifyBooleanReturn"/>

Design

To enforce some encapsulation and keep up on some standard coding design which
are known to be good for extension.

       

<\!-\- [http://checkstyle.sf.net/config_design.html] \-->
<module name="DesignForExtension"/>
<module name="FinalClass"/>
<module name="HideUtilityClassConstructor"/>
<module name="InterfaceIsType"/>
<module name="VisibilityModifier"/>

Misc

Some miscellaneous check could be added, like the ArrayTypeStyle and FinalParameter,
right now i would go with TODO: comments an specifying long as L.
I don't know but due to the international nature of Mule the Translation check
should/could be added to the Checker

       

<\!-\- [http://checkstyle.sf.net/config_misc.html] \-->
<module name="TodoComment"/>
<module name="UpperEll"/>
<module name="Translation"/> <\!-\- to the Checker \-->

I've prepared a checkstyle.xml config file for Checkstyle which you can find attached here

As usual feedback is more then welcome.

 Preferences for eclipse

Importable preferences for eclipse are attached to this page.


checkstyle.xml (text/xml)
CodeTemplates.xml (text/xml)
OrganizeImports.importorder (application/octet-stream)
Formatter.xml (text/xml)
Formatter.xml (text/xml)
CodeTemplates.xml (text/xml)
Formatter.xml (text/xml)
OrganizeImports.importorder (application/octet-stream)
Formatter.xml (text/xml)
Document generated by Confluence on Oct 03, 2006 09:23