Grundregeln
===========

* Literatur und Verweise daraus:
= C++, Programmieren, Allgemein:
    [Str98]: Bjarne Stroustrup, 
    [Mey98]: Scott Meyers, "Effektiv C++ programmieren", 3.A, AddWesl. '98,
       (Referenzen in dieses Buch sind in Lektionsnummern angegeben)
    [Cor90] oder [CLR90]: T.H. Cormen & ..., "Introduction to algorithms",
       MIT Press, '90
= Sequenzalignment  
    [Tow98]: Torsten Will, "Verbesserung multipler Sequenzalignments fuer
       das Divide & Conquer Verfahren", Diplomarbeit an der Technischen
       Fakultaet der Universitaet Bielefeld, 1998
    [Sto97]: Jens Stoye,
    [Ler97]: Martin Lermen, "Multiple Sequence Alignment", Diplomarbeit am 
       Fachbereich Informatik der Technischen Fakultaet des Saarlandes, '97
    [LR97]: Martin Lermen & Knut Reinert, "The practical use of the 
       A*-Algorithm for exact multiple sequence alignment", Techreport, 
       Max-Plank-Institut fuer Informatik, D-66123 Saarbruecken, Germany, '97
    [Alt98]: Stephen W. Altschul, "Gap costs for multiple sequence
       alignment", J.Theor.Biol, 138:297-307, '89
    [GKS95]: Gupta & Kececioglu & Schaeffer, "Improving the practical space
       and time efficiency of the shortest-path approach to sum-of-pairs
       multiple sequence alignment", J.Comp.Biol., 2:459, '95

* C- oder C++-Makros werden nicht benutzt

* Jede "class x" ist GENAU EINEM Paar Dateien zugehoerig:
  Die Datei x.hpp enthaelt alle Deklarationen, die Datei
  x.cpp alle Definitionen.

* Jede x.hpp-Datei ist in mit #ifndef H_x, #define H_x, #endif h_x 
  "geklammert" so dass auch das mehrfache Includen dieser Datei
  funktioniert.

* Eine Klassendeklarationsdatei x.hpp besteht aus folgenden Teilen:
  - Klammerung der gesamten Datei mit #ifndef H_x
  - Include von zinc: #include <zinc/zinc.hpp>
  - Include der Basisklasse: #include "???.hpp"
  - Includes von Headern aus anderen Paketen/Standardbibliotheken
  - Benoetigte Deklarationen von Klassen ("class y;") aus dem aktuellen Paket
  - typedefs die mit dieser Klasse werwendet werden
  - Die eigentliche Klassendeklaration

* Jede Klasse soll einen parameterlosen Konstruktor haben, der
  aber nur explizit (Schluesselwort) aufgerufen werden kann

* Keine Klasse hat mehrere Basisklassen

* Alle Klassen leiten sich letztendlich von Object ab (zinc/Object.hpp)

* Klassenvorfahren sind nicht virtuell, immer public

* Methoden mit Namen wie p=newXXXX() fordern Speicher an (mit new).
  Entweder muss dieser Speicher in einer korrespondierenden
  Methode deleteXXXX(p) freigegeben werden oder wird -- falls keine
  solche Methode existiert -- im Destruktor der Klasse automatisch
  freigegeben.

* Methoden mit aehnlicher Funktion wie newXXXX/deleteXXXX sind
  von Fall zu Fall anders anzuwenden. Man beachte, dass -- 
  wenn vorhanden -- die folgenen Methoden IMMER paarweise aufzurufen sind:
  - createXXXX, destroyXXXX
  - openXXXX, closeXXXX
  - allocateXXX, freeXXXX
  - grabXXXX, releaseXXXX
  = Es wurde versucht getXXXX aus dieser Grupper herauszulassen, d.h. 
    ein z.B. das oft verwendete Paar getHandle/releaseHandle existiert 
    nicht, sondern sollte grabHandle/releaseHandle heissen.
  = insertXXXX und putXXXX haben zwar oft ein Pendant removeXXXX,
    doch braucht man dieses idR nicht aufzurufen.

* Felder sind immer private. Felder haben das Praefix "m_".
  Meist gibt es Zugriffsmethoden getX und setX. Manche Zugriffsmethoden
  -- vor allem solche, die Attribute sind, die nicht direkt ueber 
  Felder implementiert sind, und daher meist ReadOnly sind -- 
  verzichten auf das Praefix "get", z.B. "size()".

* Was bedeiten die Qualifizierer bei den Methoden?
  Es ist wichtig, dass die Qualifizierer an der richtigen
  Stelle der Methodendeklaration stehen. Manche muessen dann in der
  Methodendefinition weggelassen werden (in Klammern {} angegeben).
    "access: {/** Dokumentation */}  /* Kommentar */
     {virtual} {static] inline return final 
     method(params) const throw(whatever) abstract;"
  Dabei ist:
  - access: ein Zugriffsbezeichner (der auch weiter vorne stehen kann)
    also public, protected oder private (oder nix)
  - Dokumentation: Dee Beschreibung der Methode im javadoc-Stil.
  - Kommentar: Weitere Kommentare, die nicht in einer eventuellen
      Dokumentation auftauchen sollen. Diese koennen natuerlich
      sowohl in der Deklaration, als auch der Definition stehen und
      und die /*.*/-Form oder die //-Form verwenden.
  - virtual: falls die Methode virtual ist
  - static: falls die Methode eine Klassenmethode ist
  - inline: Entweder "inline" oder "zincinl". Im ersten Fall muss die 
      der Methoden-Programmblock (die Definition) noch in der
      Header-Datei folgen. "zincinl" wird bei Methoden verwendet, deren
      Definitionen in der cpp-Datei stehen, aber doch eigentlich mal
      inline werden koennten. "inline" und der dann folgende Programmcode
      soll nur verwendet werden, wenn der Code aus einer Zeile besteht,
      z.B. fuer einfache Zufgriffsmethoden (z.B. "getX" und "setX").
  - return: Der komplette Rueckgabetyp der Methode. Hier kann auch wieder
      ein "const" stehen, zusaetzlich zum Rueckgabetyp, Referenz oder 
      Pointer. Beispiel:
      "virtual zincinl const Object* final get(int key) const;". Hier
      ist "const Object*" der komplette Rueckgabetyp.
  - final: Eigentlich "const" (siehe zinc/defs.hpp). Zeigt an, dass diese 
      Methode nicht mehr ueberschrieben werden kann. Hat C++ dieses Feature
      implementiert?
  - method(params): Der Name der Methode und ihre Parameterdeklaration.
  - const: Falls die Methode keine Seiteneffekte innerhalb des Objektes hat.
  - throw(whatever): Liste der Typen, die innerhalb der Methode ausgeloest
      werden koennen. Wird die Angabe weggelassen, kann theortisch alles 
      geworfen werden. Fuer dieses Projekt gilt: 
      Wird eine Exception geworfen, dann ist diese in der
      throw-Deklaration angegeben. 
  - abstract: In Wirklichkeit "= 0" (siehe zinc/defs.hpp) und wird fuer 
      abstracte Methoden ohne Programmcode (also Definition) verwendet.

* Default-Argumente: Auf diese ist in Konstruktoren zu verzichten!
  An anderer Stelle sind sie sparsam zu verwenden und sollen nicht
  die Funktionalitaet der Methode grundlegend beeinflussen!

* Jede statisch (global) verfuegbare Variable/Konstante muss innerhalb 
  einer Klasse deklariert/definiert sein. Auch hier sind keine 
  #defines zu verwenden, sondern "final", "static final" und "enum".


