Versions Compared

Old Version 7

changes.mady.by.user David E Tanner

Saved on

compared with

New Version 8

changes.mady.by.user David E Tanner

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0
indent
{color:green}Have any suggestion on how improve this wiki?  Please give us your feedback at [mailto:csf-support@mit.edu]{color}
Panel
Wiki Markup

Quick Links to:

{toc
:minLevel
=3}
Panel

General Naming Conventions

The Educatoinal Systems - Common Services Framework generally follows the naming conventions defined by Sun. They are listed below for reference.

Identifier Type

Rules for Naming

Examples

Packages

The prefix of a unique package name is always written in all-lowercase ASCII letters and should be one of the top-level domain names, currently com, edu, gov, mil, net, org, or one of the English two-letter codes identifying countries as specified in ISO Standard 3166, 1981.
Subsequent components of the package name vary according to an organization's own internal naming conventions. Such conventions might specify that certain directory name components be division, department, project, machine, or login names.

com.sun.eng
com.apple.quicktime.v2
edu.cmu.cs.bovik.cheese

Classes

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;

Interfaces

Interface names should be capitalized like class names.

interface RasterDelegate;
interface Storing;

Methods

Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.

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

Variables

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;

Constants

The names of variables declared class constants and of ANSI constants should be all uppercase with words separated by underscores ("_"). (ANSI constants should be avoided, for ease of debugging.)

static final int MIN_WIDTH = 4;
static final int MAX_WIDTH = 999;
static final int GET_THE_CPU =
1;

Panel
Wiki Markup

Variables

In addition to 

h3. Variables

In addition to Sun's convention, we also go a step further by naming  variables as closely as possible to the name of the class or interface  they represent.
  
  For example:


{code
}
StudentDao studentDao;
{code}

not


{code
}
StudentDao dao;
{code}

While it might seem redundant, the reason is that a developer should never  have to look through code to figure out what something is.
  
  A simple  convention such as this helps tremendously not just in our Java classes, but particularly in the case of  jsp pages where Eclipse cannot offer much help.
  
  Consider the following from a jsp page in the EC section of  Admissions:


{code
}
<c:out value="${ecAssignment.ecTerritory.ecSubRegion.name}"/>
{code}

Without  doing any research, we know based on the names above that there are classes called EcAssignment,  EcTerritory, and EcSubRegion.
  
&nbsp; Had we been lazy and named those variables something  like assn instead of EcAssignment, it wouldn't be clear to someone else  what that name represents, and it could take a lot of work to figure out  even where to even begin.