Coding Standards

Setters/Getters vs. Constructors

For Spring Managed Classes: All required properties should be set via Constructor. All optional properties should be set via setters/getters. This makes it easy to distinguish between required and optional properties.

For Non-Spring Managed Classes: These should have the option of setting all properties via constructor, as they may be instantiated inline as instance variables.

Readability

The majority of developers these days have larger, widescreen monitors. To that end, the code should favor longer lines, rather than breaking a line into multiple lines. Thus, method signatures, unless exceptionally long, should appear on one line.

The current recommendation for line length is 140 characters.

Validation

All Spring-managed classes should leverage the JSR303 Bean Validation Framework annotations for dependency checking of properties at deployment time. The default provider is Hibernate Validator.

Common Functionality

Wherever possible common functionality should be placed into an abstract or utility class, as applicable. A good example of this is the AbstractUsernamePasswordAuthenticationHandler, which most classes that use UsernamePasswordCredentials should extend from.

Specific Code Conventions

Brackets

All brackets should appear in compact form and are mandatory even for single line statements.

public class FooClass {
    public void BarMethod() {
        if (...) {
            // single line statement
        }
    }
}

Needless else clauses

We do not use needless else clauses. We would write:

public class FooClass {
    public String BarMethod() {
        if (...) {
            return "foo";
        }
        
        return bar;

    }
}

rather than

public class FooClass {
    public String BarMethod() {
        if (...) {
            return "foo";
        } else {
            return "foobar";
        }
    }
}

Indentations

Code indentation should be set to use 4 spaces. Tabs should never be used for indentation.

Simple Logging Facade

We use Simple Logging Facade. In the case where we are extending an abstract class someone else provided for us, and if they were so kind as to provide a protected Logger instance for the runtime class, we'll try to use that. In the case where we create our own Log instance, we will name it "log".

Perf4j

CAS4 utilizes the Per4j library for performance monitoring. We follow their recommended guidelines for annotating methods with @Profiled, which boils down to, if it does significant work then profile it. So, we're profiling the LDAP Authentication Handler, but not the Test Authentication Handler.

Qualifying instance variables with "this"

We qualify all instance variables with "this" with the exception of the SLF4J (named "log" or "logger"). We don't qualify that variable with "this" because it is well-known to be threadsafe. log.warn("Message") becomes more idiom than invocation of instance variable.

Use of the final keyword.

We use the keyword "final" wherever we can, because it is probably a good idea.