Contents |
Naming Conventions
General
The guidelines from this page are extracted from the Eclipse Project Guidelines.
Workspace Projects
When Eclipse is being used to develop projects, the name of the Eclipse workspace project should match the name of the project. For example, org.eclipse.core.runtime plug-in is developed in an Eclipse workspace project named org.eclipse.core.runtime.
Java Packages
Projects consist of a collection of Java packages. The package namespace is managed in conformance with Sun's package naming guidelines; subpackages should not be created without prior approval from the owner of the package subtree. The packages for the Janus projects are all subpackages org.janusproject.
The first package name segment after org.janusroject is generally the subproject name, followed by the component name.
Additional Rules
Package names should contain only lowercase ASCII alphanumerics, and avoid underscore _ or dollar sign $ characters.
Classes and Interfaces
Sun's naming guidelines states:
Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words - avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML).
Examples:
-
class Raster; -
class ImageSprite;
Additional rules:
- Interface names should be capitalized like class names.
- Interface names should be adjectives or service name, and never be ended by the word
"Interface". - The names of exception classes (subclasses of
Exception) should follow the common practice of ending in"Exception".
Methods
Sun's naming guidelines states:
Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.
Examples:
-
run(); -
runFast(); -
getBackground();
Additional rules:
- The names of methods should follow common practice for naming getters (
getX()), setters (setX()), and predicates (isX(),hasX()).
Variables
Sun's naming guidelines states:
Except for variables, all instance, class, and class constants are in mixed case with a lowercase first letter. Internal words start with capital letters. Variable names should not start with underscore _ or dollar sign $ characters, even though both are allowed.
Variable names should be short yet meaningful. The choice of a variable name should be mnemonic - that is, designed to indicate to the casual observer the intent of its use. One-character variable names should be avoided except for temporary "throwaway" variables. Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters.
Examples:
-
int i; -
char c; - float myWidth;
Constants
Sun's naming guidelines states:
The names of variables declared class constants and of ANSI constants should be all uppercase with words separated by underscores ("_").
Examples:
-
static final int MIN_WIDTH = 4; -
static final int MAX_WIDTH = 999; -
static final int GET_THE_CPU = 1;
System Files and Settings
By convention, files or folders that start with a period ('.') are considered "system files" and should not be edited by users or, directly, by other components that do not "own" them.
Of special note is the ".settings" folder in a workspace project. This folder holds various forms of preference or metadata specific to that workspace project. Files in this directory do not have to start with a period (they are assumed "system files" as they are in a "system folder") but they must follow the same naming conventions outlined elsewhere in this guide. That is, they must identify themselves with their project's namespace (e.g. org.janusproject.kernel, etc.). and they should be as specific as possible to denote the package they come from, or the function they are serving.
