Java Coding Standards

From Apache OpenOffice Wiki
Revision as of 08:08, 6 June 2008 by Np (Talk | contribs)

Jump to: navigation, search

Purpose

See the C++ Coding Standards for the general purpose of Standards.


Rules for Java

Declarations: Scoping and Names

Naming Conventions (Names)

Descriptive variable, constant and method names must be used in accord with naming conventions.

Javadoc Headers (Javadoc)

Every class / non-private method needs to have a complete header in accordance with the javadoc style. When overriding a method of a superclass this header can be omitted if the content of the superclass description is still true for the implementation of the subclass.

Comments (Comments)

Use enough comments in the code to make it understandable.

Access Modifiers (Access)

All attributes / methods must have appropriate access modifiers (private/protected/public).

Single class (SingleClass)

Each file must only contain one class (except inner classes).


Implementation Details

Static vs. Non-Static (Static)

Are there static attributes / methods that should be non-static or vice-versa?

Variable Initialization (Init)

All variables need to be properly initialized.

Constants (Const)

Are there literal constants that should be named constants
seems to be the same as MagNum ?

or are there variables that should be constants?

No Magic Numbers (MagNum)

Do not use unnamed constants in your code. Give them descriptive names.

Return Values (Return)

Every method needs to return the correct value at every function return point.

Keep Internals (Internal)

Be careful not to expose member variables by giving out mutable class references as return values. Example: String (immutable) instead of StringBuffer (mutable).

Parentheses (Paren)

Always use parentheses to avoid ambiguity.

Close I/O Resources (IO)

Opened files or connections need to be closed explicitly.


Control Flow

Switch Default (Switch)

Every switch statement must have a default case.

Switch Fall-through (FallThrough)

Every case of a switch statement should be ended by a break statement. If that is not the case and a fall-through is intended, then this must be marked by a comment.

If to Switch (IfToSwitch)

Nested if-statements should to be converted to switch-statements.


Modularity

Duplicate Code (Dupli)

Avoid and remove duplicate code. Put common code into an extra function. Duplicate code may be okay, if otherwise dependencies among so far unrelated modules would be created.

Use of Class Library Classes (Reuse)

Classes and methods from the Java class libraries should be used instead of creating an own implementation.

Make Functions Short (Short)

Make functions short. A comment line or large control structures are hints to extract functions, making the containing function more concise and readable.


Design

No Cyclic Dependencies (CyclDep)

Avoid cyclic dependencies.

No Premature Generalization (PremGen)

Do not generalize before the second occurrence and no later than the third.

One Responsibility (OneResp)

Give one class one cohesive responsibility.

How to Inherit (Inherit)

Inherit to be reused, not to reuse. Else prefer composition over inheritance.

Liskov Substitution Principle (LSP)

Everything one can do with a base class, or is offered by an interface, has to be doable with all derived/implementing classes.

Security

Validate Input (ValInput)

Validate all input coming from external

No Types Overflows (TypesOver)

Be aware that primitive types have limited range.


The first draft of these guidelines was based on the Perl Coding Standards and the Java Inspection Checklist.


Personal tools