Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

Java Coding Conventions

Indentation

Please use 4 spaces per tab.

Tip

You can access the indentation settings for Java code in Netbeans from the Tool -> Options menu.

Setup your Java Indentation settings in Netbeans to look like this.

Naming

In general, abbreviations should not be used in naming.

Method Names

Methods should be named with a verb and a noun. The noun should be capitalized.

Please do not use underscores in Java names.

Here are examples of good method names.

Code Block
computeSum()
getX()
setY()

Getters should start with get and setters should start with set. Method names
such as x() instead of getX() are ambiguous.

Variable Names

Variables should start with a lowercase letter. Subsequent words should be capitalized.

Here are examples of variable names.

Code Block
thetaIndex
phiBins
binValues

No distinction is made between local variables and member variables as far as naming conventions.
To disambiguate local and member variables, use the this keyword.

For instance, this is a perfectly valid way of assigning a member variable that has the same name
as the method argument.

Code Block
void setFoo(int foo)
{
    this.foo = foo;
}

Interfaces and Implementations

Java makes a distinction between interfaces, which have no method bodies, and implementations,
which are classes that may also be abstract. There is no distinction made in naming conventions
between abstract and non-abstract (concrete) classes.

Info

Abstract classes have some functions without method bodies. These are indicated with the abstract keyword.

In general, the interface should have the "natural" name. For instance, an interface could be
called Identifier, while the implementation should have a suffix such as Basic, Base or
Impl as in IdentifierBase. Using some other suffix to identify an implementing class, such
as in IdentifierExpanded, is probably fine, too.

Even better is to separate the implementations into a subpackage such as org.lcsim.ids.impl.