- •2.1 Introduction 6
- •3.1 Introduction 14
- •2.2Abbreviations
- •2.3Packages
- •2.4Classes
- •2.5Interfaces
- •2.6Annotations
- •2.7Exceptions
- •2.8Enumerations
- •2.9Fields
- •2.10Static Fields
- •2.11Parameters
- •2.12Methods
- •2.13Field Accessors (Java Bean properties)
- •2.14Generics
- •2.15Summary
- •3.4Inline comments
- •4.Code formatting
- •4.1Indentation, spaces and braces
- •4.2Separation of operators and punctuators
- •8.Appendices Appendix a
2.3Packages
The general rule for naming packages is to use reversed company domain followed by the project name and optionally the feature or module name (which can be followed by sub-feature or sub-module name):
domain.companyname.projectname[.module][.submodule]
For example (code belonged to Itransition www.itransition.com):
com.itransition
com.itransition.project
com.itransition.project.ui
Or for offshore code:
com.day.crx
com.day.crx.sharepoint
com.day.crx.documentum
com.cya.recyclebin
com.cya.recyclebin.web
The following rules should be used for naming packages:
Use lower case for packages, and separate logical components with periods, as in java.lang.annotation. If your brand employs nontraditional casing, package name should be forced to lower case anyway. For example, packages com.day.crx.sharepoint, com.cya.recyclebin.web.
Use singular namespace names (like java.util) if it is semantically appropriate. For example, use org.example.util rather than org.example.utils.
2.4Classes
The following rules outline the guidelines for naming classes:
Use a noun or noun phrase to name a class.
Use Pascal case.
Do not use the underscore character (_).
Do not use a type prefix, such as C for class, on a class name. For example, use the class name InputStream rather than CInputStream.
Exception class name should always be suffixed with “Exception”.
Where appropriate, use a compound word to name a derived class. The second part of the derived class's name should be the name of the base class. For example, ApplicationException is an appropriate name for a class derived from a class named Exception, because ApplicationException is a kind of Exception. Use reasonable judgment in applying this rule. For example, Button is an appropriate name for a class derived from Control. Although a button is a kind of control, making Control a part of the class name would lengthen the name unnecessarily.
For example:
Sign
VerifiableStream
ExternalContractException
TransformationMatrix
2.5Interfaces
The following rules outline the naming guidelines for interfaces:
Name interfaces with nouns or noun phrases, or adverb that describe behavior. For example, the interface name List uses a descriptive noun. The interface name DataInput uses a noun phrase. The name Comparable uses an adverb.
Use Pascal case.
Do not use the underscore character (_).
Do not use a prefix, such as I for class, on a interface name. For example, use the class name List rather than IList.
Use similar names when you define a class/interface pair where the class is a standard implementation of the interface. The names should differ only by the word Bean (for EJB based applications) or Impl (for POJO based applications) sufixes on the class name (for example, UserService and UserServiceImpl or UserServiceBean). To name abstract class that partially implements interface <Name> use Abstract<Name> identifier (for example, TreeModel and AbstractTreeModel).
The following are examples of correctly named interfaces:
public interface ApplicationContext { … }
public interface Orderable { … }