Coding Standards

This page describes standard coding practices, and is intended to be an aid for developers as they write code. Code reviews will be conducted to ensure we are following our standards.

General

1. DWR (Direct Web Remoting) is deprecated. New projects should not contain any references to DWR.
2. All XML schema definition (XSD) locations in project XML files should be declared without version numbers. Version numbers seem to make the app look on the internet for the XSD; omitting the version numbers forces the XSD bundled in the jar files to be used.

For example, DO THIS:

xsi:schemaLocation="
    http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans.xsd"

DO NOT DO THIS:

xsi:schemaLocation="
    http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans-3.0.3.xsd"
                                                             ^^^^^ NO!!!

Web/Controllers

1. In a Spring MVC web application, controller classes should not extend any Spring framework classes.
2. Controller classes should be identified to Spring as a controller bean by using the @Controller annotation.
3. Request URLs should be mapped to controller classes and methods by using the @RequestMapping annotation.
4. Generally speaking, we aim to configure controllers by using annotations.
5. We should use the @Autowired annotation for injected dependencies.
6. As controllers are typically configured as singletons in the Spring context, the classes should be thread-safe. In practical terms, this means fields, or instance variables, should never maintain any state, and they should not be instantiated by the new  operator. The only instance variables in a controller should be other Spring beans, injected by the Spring container. Typically these will be service classes or helper classes.
7. Controllers should not contain any business logic - they should be concerned with UI-related logic. Business logic should be delegated to service classes.

Service Classes

1. Service classes should be identified to Spring as a service bean by using the @Service annotation.
2. Generally speaking, we aim to configure service classes by using annotations.
3. We should use the @Autowired annotation for injected dependencies.
4. As service classes are typically configured as singletons in the Spring context, the classes should be thread-safe. In practical terms, this means fields, or instance variables, should never maintain any state, and they should not be instantiated by the new  operator. The only instance variables in a controller should be other Spring beans, injected by the Spring container. Typically these will be DAO classes or helper classes or other service classes.
5. Service classes should contain only business logic - they should NOT be concerned with the user interface. Neither should they be concerned directly with data retrieval. Data retrieval should be delegated to DAO or other service classes.

DAO Classes

• DAOs do not extend Spring’s HibernateDAOSupport class.
• DAOs should not extend any other class.
• DAOs should include a private instance variable DaoFoundation, injected by Spring via the @Autowired annotation. The DaoFoundation class provides most of the methods necessary to communicate with the Hibernate session. For Hibernate operations not directly supported by DaoFoundation, the Hibernate Session and SessionFactory objects are available via the DaoFoundation.
• DAOs should not use Spring’s HibernateTemplate. HibernateTemplate for Hibernate 3 is deprecated, and does not exist at all in Spring's Hibernate 4 module.

Domain Classes

• Domain classes to be used as Hibernate managed entities should extend AbstractDomainBase. This automatically provides certain attributes (version, create date & user, modify date & user) and allows Hibernate to automatically maintain these attributes.
• Domain classes should normally be very simple POJOs with attributes and accessors. Business logic is typically implemented in service classes.
• Domain class getter methods should never modify attributes.

Java - General

• Use constants declared as static variables rather than hard-coding values in the Java code.
• Place instance variables at the top of the class; getters and setters at the bottom of the class.
• Use log level of “debug” unless there’s a specific reason to use info or error.
• An exception that is intercepted in a "catch" block should be re-thrown, unless there is a specific reason for not re-throwing. As a rule, do not simply have a catch block log a message and continue.
• Methods and classes should be documented accurately with javadoc.
• All methods should have corresponding unit tests.