 There are certain conventions that have evolved as CORAL was being
developed. I'll attempt to list some of them here :
\begin{itemize}

\item All externally visible functions, classes, and variables should
    be prefixed with {\bf Cor\_}, to avoid naming problems when Coral
    is used with other systems.  This is a temporary measure until
    C++ {\em namespaces} are in the standard and implemented reliably.

\item We currently use the CVS system for version control. This avoids
    any problems with breaking locks and contention, and assists
    programmers in merging their changes. 

\item Make sure that you run the regression test suites before checking
    in your modified files. At all times, the checked in version
    should be consistent.

\item When you are checking in a large bunch of files together,
    put in a detailed description of all the changes you are making.
    If you are making conceptual changes to how Coral works, add
    some external documentation in /p/coral/doc as well.

\item All debugging-type code should be enclosed within an \#ifdef DEBUG.
    Similarly, there are flags for TRACE, EXPLAIN and PROFILE, and
    other things, check in CONFIG for the full list.
    In any external release, the DEBUG flag is assumed to be off.
    Whenever adding new code, it should be kept in mind that the
    current CVS version should be ready for release at a day's notice.

\item Right now, the system compiles with g++ as well as CC on DECstations,
SPARCs and HP 700s. We want it to stay that way. Try not to use features
that are specific to a machine, or a compiler. For example, if you want to
use C++ templates, I'd rather you worked around it, until template code is
stable for CC and g++. Backward compatibility is also important; I get
messages from people using AT\&T C-front version 1.*.

\item It is important that algorithms, etc. be provided as comments. Right
now, much of the code is poorly commented, but there's no point adding to
the problem.  If necessary, append your initials or your name to the comments.

\item Different conventions have been used in different parts of the code
for function names, variable names, etc. It is probable that you will be
extending existing parts of the system. In that case, please try to be
environmentally friendly, and stick to the naming conventions used there
already. If you are adding a brand new component to the system, try to use
some standard approach all the same. Same holds for indenting: much of the
code has several levels of nesting: therefore, keep indenting small.
Need I say this: keep variable names meaningful, minimize globals and gotos.

\item We have learned the hard way that it makes sense to write efficient
code the first time through. Too often, an inefficient hack has been
thrown in, and has then been forgotten. If you want to do this, put in
a comment with a label on it, and before you check in your code, grep for
the label, and make sure you fix all inefficiencies. It is a lot more
painful to go back later and try to improve stuff (especially if you're
not the one that wrote it in the first place).

\item Remember that we are still primarily a main-memory system. We {\bf have}
to keep our code efficient, especially the run-time code. Gross hacks to this
end are undesirable, but the definition of gross changes depending on how 
much efficiency it will buy.

\end{itemize}
