Standards.txt - All implementations should follow these. - JH

=======================================================
       >>>>> MINIMAL CODING STANDARDS <<<<<

 Code must be very understandable. THE MOST IMPORTANT
    IMPLEMENTATION GOAL IS UNDERSTANDABILITY, BY BOTH
    THE USER AND DEVELOPER.

 Comment all classes and public methods fully.
 Use comments liberally.
 Use white space to deliniate intentional blocks.

 All code must satisfy our architectural requirements.
 A current high level model must exist for all code.

 Start all classes with the template, keep organized.
 Emulate JavaSoft code for curly brace and indent style.
 One outer class or interface per file.

 A good class does one thing and does it well.
 Strive for low coupling, high cohesion.
 Keep it simple. Be conservative.
 
 Use very careful naming. This makes code self documenting.
 Start class names with an upper case letter.
 Start method and variable names with a lower case letter.
 No magic numbers or cryptic variable names besides i, j, k
 
 Use no-arg constructors only when appropriate.
 All class fields should be private except for constants.
    An exception is protected or public constant fields.
 All classes must support the bean spec code patterns.
 Recursive methods must be documented as RECURSIVE.
 Minimize inheritence. Use composition instead.
 Keep classes under 200 LOC plus comments, with deliberate exceptions.
 Separate properties from internal fields.
 
 IF - Always use braces unless on same line with if and short statement.

 List custom imports before java imports.
 Alphabetize imports but group for clarity.
 All lowercase package names.
 Explicitly import classes unless many from same package.

 Good code should be so well written and follow these
    standards so closely that you cannot tell who wrote
    it, except for the author's name. Be humble....

======================================================
    >>>>> Lesser known terms <<<<<
Plugpoint - A settable property that allows a different
class to be used. A clean way to do this is the
property is the class name (a String) to be instantiated.
The class with the property internally uses an interface
which the pluggable class implements. This is very clean.

Note the class can be the Fascade for an entire subsystem,
or just an Adapter for one class. Strive to design in
plugpoints to avoid "monolithic monsters".

======================================================
Note - These naming conventions were started late, on
1/31/98. Thus they are immature. I hope to add to them
as I wade through the code....

======================================================
    >>>>> Class Naming Conventions - Suffixes <<<<<

Note the suffix is the class role.

-- Well known patterns -----
View, Model, Controller - Per standard MVC Pattern. The
    controller is generally a business object.
Proxy - Per standard Proxy Pattern
Factory - Creates instances on demand

-- Other -----
Mgr - Manages a collection or subsystem
Def - Defines a parameter used in another class, which has
    multiple such definitions. Often parameter driven.
Accessor - Carries data for accessing something
Pool - Provides a collection of instances ready for work
Set - Contains a set of like items, ie a RowSet contains rows

Lib - Library with all static fields and methods
Row, Map - Collection of name/value pairs
Event, Listener - Per Java beans spec
Source - An event source. Emits callbacks.
Supplier - Supplies instances on demand.
Std - Standard interface implementation of something

Test - The unit test for a class
Services - Fascade for a subsystem, ie DatastoreServices

======================================================
    >>>>> Method Naming Conventions <<<<<

Follow the Java Bean spec for getters, setters, boolean
properties, events, listeners.

------- Method Prefixes ----------

-- Simple accessors

getPropertyName() - This should return the same
value every time, unless its been changed by a set() or
the class has done some "significant" internal change.
Calling get() should not cause lots of work or state change,
to allow class inspection.

createXXX() - Use this when a different, and probably new,
instance is returned every time. For example a Factory
will have a createXXX(), and Services classes often have them.

loadXXX() - Use this when neither getXXX() or createXXX()
is appropriate. (not sure what's a good standard here)

-- Other
add, remove, removeAll - Just like in the Jave classes.
(or use clear?)
