Zuletzt gemachte Änderungen sollen durch Fettschrift markiert werden.

Autoren: HelmutLeitner, RalfEbert
Diskussion siehe ProgrammierStilAlphaDiskussion

1. Ziel von PSA ist die Verwendbarkeit für mehrere Programmiersprachen. Explizit geht es um: C, Java, Perl, Tcl, etc. . Geringere Priorität haben zur Zeit: Pascal, BASIC, etc. .
2. Objektorientierte Programmierung wird angestrebt, jedoch in einer sanften Form, die sich sich auch in einer prozeduralen Sprache umsetzen läßt. Also keine komplexen Hierarchien, sondern eher isolierte, mächtige Klassen.

1. Mehrsprachigkeit bzw. Übersetzbarkeit
1. Übersetzbare Bezeichner. Es sollen nur Bezeichner eingesetzt werden, die nach Entfernung sprachspezifischer Sonderzeichen und Umwandlung in Kleinschreibung eindeutig bleiben. Dies dient der Übersetzbarkeit bzw. dem Aufbau gemeinsamer APIs und vereinfacht die mündliche Kommunikation. Die C-Variablen Xy und xY sind unzulässig, weil sie sich nicht eindeutig in caseinsensitives BASIC übersetzen lassen. Ebensfalls unzulässig wären die Perl-Variablen %hash und $hash oder die BASIC-Variablen I% und I#.
2. OOPP-Harmonisierung. Um objektorientierte und prozedurale APIs unter einen Hut zu bringen, werden das objektorientierte Object.ActionProperty(property) und das prozedurale ObjectActionProperty(object,property) als semantisch äquivalent betrachtet. Tatsächlich sind diese Formen durch die impliziten Übergabe des "this"-Pointers funktionell (auf Maschinensprachebene) äquivalent.
3. Keine unübertragbaren Sprachelemente in APIs. Es sollen für APIs keine Sprachelemente eingesetzt werden, die in anderen Sprachen nicht nachbildbar sind. Ein Hash in Perl ist ok, das kann in C oder auch Basic nachgebildet werden. Java-Exceptions sind nicht ok, weil in Perl oder BASIC kein Äquivalent dafür nachgebildet werden kann.

2. Konsistenz
1. Dictionary. Funktionsnamen (APIs) sollen aus Worten gebildet werden, deren Bedeutung in einem projektbezogenen Dictionary dokumentiert wird. Dabei ist genaue Schreibweise weniger wichtig, als die Erkennbarkeit der Worte. Die Bezeichner file_delete, FileDelete, fileDelete oder FILE_DELETE sollen als semantisch äquivalent gelten. Die Vorzugsschreibweise wird im Projekt festgelegt. Dieses Dictionary bildet praktisch eine Beschreibungssprache für die Programme des Projekts.
2. Konsistente Funktionsnamen. Als Weg zu konsistenten APIs sollen die Worte in den Funktionsnamen so weit wie möglich mit der Art und der Reihenfolge der Parameter abgestimmt werden. Im Projekt wird festgelegt, ob Verkürzungen zulässig sind, und falls ja, welche. Z.B. ist copyStringToBuffer(char *string, char *buffer) korrekt, die Standard-C-Funktion fgets(buffer,buffersize,file) jedoch nicht. Die letztere Funktion könnte in einem konformen System z.B. FileReadBufferSize(file,buffer,size) lauten. Günstig ist die Einleitung des Funktionsnamen mit dem zentralen Objekt. Z.B. statt copyStringToBuffer(char *string, char *buffer) besser stringCopyToBuffer(char *string, char *buffer). Dies ist bei Bedarf leicht in ein string.copyToBuffer(char *buffer) umzusetzen.
3. Konsistente Verwendung von Variablen. Innerhalb eines Moduls (eines Sourcefiles, einer Klasse) darf ein Variablenname nicht für semantisch unterschiedliche Zwecke eingesetzt werden. Nach Möglichkeit soll diese Konsistenz auf größere Organisationseinheiten (Teilprojekt, Library) ausgedehnt werden.
4. Objekt-Verantwortung. Der Aufrufer ist für die Gültigkeit der an eine Funktion übergebenen Objekte verantwortlich. Nur bei "Finalisierungsfunktionen" (Destruktoren, Close-Funktionen, ...) muss die Funktion auch ungültige Objekte (NULL, null, etc.) tolerieren.
5. Fehlerstatus. Der Fehlerstatus einer Funktion wird im Returnwert entweder explizit übergeben (kein Fehler=0, Fehler=negativer Wert), oder als Nebeninformation (Pointer=NULL, Tabellenindex=negativ).
6. Strukturierte Programmierung. Die Regeln der strukturierten Programmierung sollen eingehalten werden. Falls der normale Schleifenablauf durch break oder continue (bzw. analoge Konstruktionen anderer Sprachen) durchbrochen wird, ist das durch Kommentare optisch deutlich zu kennzeichen. Vorzeitige return- bzw. exit-Befehle sollen vermieden werden.
7. Einheitlicher Klammernstil. Wenn im Projekt nicht anders festgelegt gilt der Java-Klammerstil, "cuddled-else" und "geklammerte" Bedingungen und Schleifen. Dies läßt eine idente Strukturierung auch bei klammernlosen Sprachen zu. Der festgelegte Stil wird auf alte Sources bei der nächsten Überarbeitung angewandt.
8. Keine Mehrfachbefehle. Mehrere Befehle in einer Zeile sind nicht erwünscht. Unerwünscht sind die Deklaration und Definition mehrerer Variablen in einer Zeile. Unerwünscht ist auch die einzeilige Schreibweise von Bedingungen oder Schleifen.
9. Keine Tabulatorzeichen. Sourcefiles dürfen keine Tabularzeichen enthalten. Die Einrückungstiefe beträgt 2, 3 oder 4 Zeichen. Ein Vorzugs-Einrückungstiefe wird im Projekt festgelegt (empfohlen: 2) und auf alte Sources bei der nächsten Überarbeitung angewandt.
10. Kommentare. Selbstverständlichkeiten sollen nicht dokumentiert werden. Kommentare sollten so gestaltet werden, daß mit ihrer Hilfe durch DokumentationsTool eine brauchbare Dokumentation erzeugt werden kann.

Das verwendete Tool wird in dem jeweiligen Projekt festgelegt.

3. Schnittstellen
1. Entkoppelung des User Interface. Funktionale Programmteile und Benutzeroberfläche müssen entkoppelt sein. Zu der Benutzeroberfläche zählt alles, was zur Kommunikation mit dem Benutzer gehört; Aufrufparameter für Programme ebenso wie eine etwa vorhandene grafischen Oberfläche.
2. GUI-Beschreibungssprache. GUIs sollten in einer prorammiersprachenunabhängigen GuiBeschreibungssprache definiert werden, z.B. XUL oder UIML. Die Festlegung erfolgt im Projekt.
3. Binäre Dateiformate. Sollen nur verwendet werden, wenn sie aus Platz- oder Performancegründen notwendig scheinen. Die Spezifikationen müssen eindeutig sein und dürfen nicht auf vagen Typangaben (z.B. int der SpracheCee) beruhen. Alignment und Padding-Bytes müssen klar hervorgehen. Die Dateien müssen entweder big-endian oder little-endian spezifiziert sein, oder über den Header ihre "endian-ness" bekanntgeben. Portabilität wird nur für 8*2^N-Bit-Architekturen angestrebt. Der Standard für die Formatbeschreibung und allfällige Einschränkungen werden im Projekt festgelegt.

• Es werden nur die für die jeweilige Programmiersprache typischen, einfachen Sourcefile-Extension verwendet: z.B. ".c", ".cpp", ".java", ".pl", ".h" oder ".hpp". Unzulässig wäre z.B. ein C-Sourcefile mit der Extension ".cx" oder ".x.c".
• Die Benennung von Files soll sich nicht darauf stützen, dass das Betriebssystem Groß-/Kleinschreibung unterscheidet bzw. mehrere Extensions in einem Filenamen zuläßt.
• Die Fileorganisation soll dem Modul- bzw. Klassenaufbau entsprechen.
• Vorschriften über die Länge von Zeilen (nicht zu lang) oder die Formatierung von Kommentaren werden dem guten Geschmack der beteiligten Programmierer überlassen.
• Programme sollten über eine Hilfsfunktion mit einer Beschreibung der Parameter verfügen.