Convention |
Example |
Notes |
Names representing packages should be in all lower case. |
org.mule.application |
Package naming convention used by Sun for the Java core packages. The initial package name representing the domain name must be in lower case. |
Names representing types must be nouns and written in mixed case starting with upper case. |
EsbMessage, OrderService |
Common practice in the Java development community and also the type naming convention used by Sun for the Java core packages. |
Variable names must be in mixed case starting with lower case. |
message, newOrder |
Common practice in the Java development community and also the naming convention for variables used by Sun for the Java core packages. Makes variables easy to distinguish from types, and effectively resolves potential naming collision as in the declaration Line line; |
Names representing constants (final variables) must be all uppercase using underscore to separate words. |
MAX_ITERATIONS, COLOR_RED |
Common practice in the Java development community and also the naming convention used by Sun for the Java core packages. |
Names representing methods must be verbs and written in mixed case starting with lower case. |
getName(), computeTotalWidth() |
Common practice in the Java development community and also the naming convention used by Sun for the Java core packages and the JavaBean specification. This is identical to variable names, but methods in Java are already distinguishable from variables by their specific form. |
Abbreviations and acronyms should not be uppercase when used as name. |
exportHtmlSource();
NOT: exportHTMLSource();
openDvdPlayer();
NOT: openDVDPlayer(); |
Using all uppercase for the base name will give conflicts with the naming conventions given above. A variable of this type whould have to be named dVD, hTML etc. which obviously is not very readable. Another problem is illustrated in the examples above; When the name is connected to another, the readability is seriously reduced; The word following the acronym does not stand out as it should. |
Underscores and other special characters should NOT be used in varable names, method names or class names |
private String name;
NOT private String name_; |
Often private member variables are given an underscore '_' prefix to denote it's private member status. Mule does not use this convention as Java Editors make the status of variables know through color coding. |
Generic variables should have the same name as their type. |
void setTopic(Topic topic)
NOT: void setTopic(Topic value)
NOT: void setTopic(Topic aTopic)
NOT: void setTopic(Topic t)
void connect(Database database)
NOT: void connect(Database db)
NOT: void connect(Database oracleDB) |
Reduce complexity by reducing the number of terms and names used. Also makes it easy to deduce the type given a variable name only. If for some reason this convention doesn't seem to fit it is a strong indication that the type name is badly chosen.
Non-generic variables have a role. These variables can often be named by combining role and type:
Point startingPoint, centerPoint;
Name loginName; |
All names should be written in English. |
|
English is the preferred language for Mule development. |
The terms get/set must be used where an attribute is accessed directly. |
employee.getName();
employee.setName(name);
matrix.getElement(2, 4);
matrix.setElement(2, 4, value); |
Common practice in the Java community and the convention used by Sun for the Java core packages and the JavaBean Specification. |
'is' prefix should be used for boolean variables and methods. |
isSet, isVisible, isFinished, isFound, isOpen |
This is the naming convention for boolean methods and variables used by Sun for the Java core packages and the JavaBean specification. Using the is prefix solves a common problem of choosing bad boolean names like status or flag. isStatus or isFlag simply doesn't fit, and the programmer is forced to chose more meaningful names. |
Negated boolean variable names must be avoided. |
boolean isError;
NOT: isNoError
boolean isFound;
NOT: isNotFound |
The problem arise when the logical not operator is used and double negative arises. It is not immediately apparent what !isNotError means. |
Associated constants (final variables) should be prefixed by a common type name. |
final int COLOR_RED = 1; final int COLOR_GREEN = 2; final int COLOR_BLUE = 3; |
This indicates that the constants belong together, and what concept the constants represents. |
Interface and class names should avoid abbreviations, be descriptive and be camel-cased. |
interface OrderService
NOT: interface OrderServ |
|
Abstact classes should be prefixed with 'Abstract'. |
class AbstractOrderService implements OrderService
NOT class OrderServiceAbs implements OrderService |
|
Exception class names should be suffixed with 'Exception' |
EngineFailureException extends Exception
NOT: EngineFailure extends Exception |
|
Default interface implementations can be prefixed by 'Default'. |
class DefaultOrderService implements OrderService
NOT: class OrderServiceImpl implements OrderService |
It is not uncommon to create a simplistic class implementation of an interface providing default behaviour to the interface methods. The convention of prefixing these classes by Default has been adopted by Sun for the Java library. |