GSMP - General Sound Manipulation Program
(c) 2000-2002 Ren Rebe and Valentin Ziegler

Information for syntax and coding conventions in GSMP or one of its
basic libraries.

General guide:
--------------

- The main programming language used in GSMP is C++.

- All modern object-oriented design-methods should be used.
	- defining abstract interface classes
	- using object hierachies
	- creating generic templates where possible
	- using exceptions (athough the gcc doesn't support them
	  that well ...)
	- using the STL where resonable
  
  A good starting point to learn more about this:

  1: The C++ Programming Language - Bjarne Stroustrup
  2: The C++ Standard Library - Nicolai M. Josuttis
  3: Design Patterns - Erich Gamma, Richard Helm, Ralph Johnson and
     John Vlissides

(Since some of this conventions are new (and we changed them over the
time) GSMP still needs to be adapted to comply to them.)

Naming / syntax conventions:
----------------------------

We changed this conventions many times we learned more and more about
C++, so our older code doesn't match them.

Naming:

- Class and method names have capital letters at the beginning and on
  word boundaries. e.g.: MixerNode, GsmpCanvas, PcmBuffer ...
- Instance names start with an non-capital letter and _ on word boundaries.
  e.g.: current_layer
- Constructor parameter should start with an i_ (for init)
- agregated objects should start with an m_ (for my)
- temporary calculated stuf in methods should start with t_ (temp)

Syntax:

- identing space it the XEmacs default of two characters
- between names and operators should be one space. e.g.:
	- t_layer -> Length ();
	         ^  ^      ^
- pointer and references should be specified without space after the
  type. e.g.:
	- MixerNode* t_mixer;
	           ^
	- VoodooClass::SetStart (const sample_index& start);
	                                           ^
  This reflects that it is a pointer or reference TYPE!
- Namespace or scope operator should not be sperated by spaces. e.g.:
	- Gsml::TrackLayer::iterator i ....
	      ^^          ^^

Namespaces:

- related classes should be grouped in namespaces

- using namespace directives should not used in .hh header files -
  normall the namespace should be specified for all used objects. (See
  the several arcticles about this in the CUJ ...)

Preprocessor Tricks:

- #define should be avoided and constants in the name space should be
  used.

- #ifdef-style code should be avoided. Even for debug stuff. There is
  nothing that can not be done in C++ code! Debug statments can be
  eliminated by the compiler, if the expression is determinalble
  during compile time. This way we make sure the debug code is
  syntactically correct even when we develop with debugging
  disabled.
