Naming Conventions


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).


  • 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".


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.


  • run();
  • runFast();
  • getBackground();

Additional rules:

  • The names of methods should follow common practice for naming getters (getX()), setters (setX()), and predicates (isX(), hasX()).
  • When the verb used to build the method's name is compute, calculate, or something similar, it is avoid in the method's name. For example, we should write distance(a,b) in place of computeDistance(a,b). Note that distance(a,b) and getDistance(a,b) reply the same value, but in the first the distance is the result of a computation, and in the second, the distance may be computed or stored.


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.


  • int i;
  • char c;
  • float myWidth;


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 ("_").


  • 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.

Related Pages

2016-01-24SARL 0.3.1 and Janus are available.
2015-11-30SARL 0.3.0 and Janus are available.
This page was last modified on 12 November 2013, at 13:04. This page has been accessed 8,788 times.
Copyright 2010-2017 © Janus Core Developers - Privacy policy