• Wie ist das: Ich markiere selbst definierte Typen und Klassen, indem ich diese mit einem Großbuchstaben beginnen lasse, Strukturen beginnen mit einem _ und alle anderen Namen mit einem kleinen Buchstaben. Z.B.

typedef struct Word { char *spelling; /* spelling of the word */ unsigned short type; /* * type of the word * possible values are: * 0 = unknown * 1 = noun * 2 = verb * 3 = article * ... */ unsigned short flags; /* * further classification, dependent * on the type */ } Word; . . . Word word;

Würde das dem obigen Absatz widersprechen? Kleine Korrekturen ok (_ am Bezeichneranfang ist laut Standard für das System reserviert)? Nein, da würde nichts widersprechen.

• Sachen gibts --- ich wusste gar nicht, daß der Compiler das auch so schluckt :-). Ich probiere das am Montag mal unter verschiedenen Systemen aus (die C-Compiler von Microware sind da etwas eigenwillig). Er muss laut Standard, es sind verschiedene Namespaces.
• Du weißt, daß die tabellarische Anordnung ein Mittel ist, um die Übersichtlichkeit zu erhöhen?
• Entschuldige, ich dachte, das wäre unabsichtlich verrutscht. Irgendwie würde das den Einrückungsnormen zuwiderlaufen, oder nicht? Aber ich glaube nicht, dass wir das reglementieren sollten. Vielleicht können wir am Ende ja solche Details noch aufeinander abstimmen und aneinander annähern. Ich würde das z.B. in meinem Bereich normalerweise so schreiben (nur zur Information, überflüssige Kommentare weggelassen):

(#define CH char) (#define US unsigned short) typedef struct Word { CH *spelling; US type; /* 0=unknown, 1=noun, 2=verb, 3=article */ US flags; /* classification depending on type */ } Word;

Aber das sind persönliche Besonderheiten (aus Faulheit CH UC SC UI IN LO UL VO FL DO), die ich nicht in unsere Projekte oder Stile hineinpressen will. Ich habe allerdings nie verstanden, warum die Leute so gern tippen.

• Wenn du dich jemals bei einem Projekt, bei dem es brennt, durch einige tausend Zeilen Code von einem Entwickler durchgearbeitet hast, der ausschließlich Variablennamen wie a, b, c, ..., aa, ab, ac, ... benutzt hat (und dabei selbst durcheinander kam), würdest du es vermutlich verstehen. Die lange Schreibweise ist im Prinzip nur das gegenteilige Extrem. Ich verwende sie halt zur Dokumentation. char *deutschesWort, *fremdesWort; erscheint mir weniger fehlerträchtig als char *dw, *fw; /* dw: deutsches Wort, fw: fremdes Wort */ . Dafür nehme ich schon gerne etwas mehr Schreibarbeit in Kauf. Variablen wie i, x, ... verwende ich im Normalfall nur als Laufvariablen o. ä. .

Im übrigen sollten wir Grundtypen schon definieren, da dies den Austausch von Libraries erleichtern würde. Wie wäre es mit der Form char, u_char, int8, u_int8, int16, u_int16, ...?

• Ein Missverständnis. Die langen Namen sind perfekt, wir denken komplett gleich, nur bei "char *spelling; /* spelling */" habe ich Probleme, denn wozu programmiert man dann lesbar.
• Das war ein Fehler in der Überarbeitung. Ursprünglich hies das Element Wort. Allerdings können wir das Teil ja als Beispiel lassen, wie man es nicht machen sollte.
• Der Einrückung würde eine tabellarische Anordnung nicht widersprechen, da es sich bei der Einrückung nur um die linke Textmarke handelt. Ich habe nämlich auch etwas gegen überlange Zeilen und rücke die Folgezeilen etwas ein. Bei Funktionen stehen z.B. die Parameter untereinander, bei Termen, die Elemente der Teiltermen, ...

• Für die nicht arabisch schreibenden sollte auch deleteFile als semantisch äquivalent gelten. Gibt es einen bestimmten Grund für den Aufbau der Namen von rechts nach links? --RalfEbert
• Ja, die nachfolgend eingefügten zwei Punkte. [Jetzt unter den Punkten "Konsistente Funktionsnamen" und "OOPP-Harmonisierung"]
• Übrigens sehe ich das nicht als "von Rechts nach Links". Ich kann befehlen "lösche den File" oder ich möchte "den File löschen". Das ist mehr eine Frage ob ich die Aktion "Löschen" oder das Objekt "File" zuerst sehe.
• Das Problem war, daß deine Beispiele in der Wörterbuch-Mailingliste auch von rechts nach links angelegt waren und da hat mein interner Parser anscheinend etwas zu viel optimiert. Wie ja bereits gesagt, mit dem Argument string.copyToBuffer(buffer) kann ich gut leben.

Also z.B. WindowSetTitelText(window,titel,text) und nicht WindowSetTitelText(window,text,titel). Als Beispiel die Inkonsistenz zwischen der (nach dieser Regel korrekten) C-Funktion fprintf(file,format,...) und der diese Regel verletzenden Funktion fgets(buffer,buffersize,file). Die letztere Funktion könnte in einem konformen System z.B. FileReadBufferSize(file,buffer,size) oder verkürzt FileReadBuffer(file,buffer,size) lauten.

• Ich halte die Möglichkeit einer Verkürzung nicht für sinnvoll. Gut, bei FileReadBufferSize(file,buffer,size) bzw. FileReadBuffer(file,buffer,size) wäre es eventuell denkbar, aber bei copyStringToBuffer(char *String, char *buffer) und copyStringToBufferSize(char *String, char *buffer, size_t size) sollte das nicht möglich sein. Daher wäre ich für ein generelles Verbot von Kurzformen. Man könnte size bei C++ zwar durch einen optionalen Parameter realisieren, was aber der nächsten Regel widerspricht. Ferner würde eine Verkürzung auch dieser Regel selbst widersprechen.
• Ich finde einen Namen wie copyStringToBufferSize fürchterlich, FileReadBufferSize schießt den Vogel ab. Der Name einer Routine sollte aussagen was diese Routine leistet und nicht aus den Namen seiner Parameter bestehen. Wie sieht es denn dann aus wenn noch ein Parameter hinzukommt? Dann haben wir FileReadBufferSizeFilter(file, buffer, size, filter). FileReadBufferSize hört sich so an, als ob die Größe eines Puffer eingelesen werden soll und FileReadBufferSizeFilter klingt als lese ich die Filterdefinition für eine Puffergrößenangabe. Eigentlich bin ich ein Freund von overload. ReadBuffer würde mir vollkommen ausreichen. Wie die Routine genutzt wird erkenne ich anhand der Parameter. Und eine gute IDE zeigt mir bei Bedarf die verschiedenen Parameterlisten an die ich verwenden könnte. Wenn die übergebenen Variablen gut Namen haben ist der Code genausogut zu lesen:

FileReadBufferSize(inputFile, textBuf, TEXT_BUF_SIZE); FileReadBufferSizeFilter(inputFile, textBuf, TEXT_BUF_SIZE, ascciFilter); StringReadBufferSize(inputText, textBuf, TEXT_BUF_SIZE); StringReadBufferSizeFilter(inputText, textBuf, TEXT_BUF_SIZE, ascciFilter); ReadBuffer(inputFile, textBuf, TEXT_BUF_SIZE); ReadBuffer(inputFile, textBuf, TEXT_BUF_SIZE, ascciFilter); ReadBuffer(inputText, textBuf, TEXT_BUF_SIZE); ReadBuffer(inputText, textBuf, TEXT_BUF_SIZE, ascciFilter);

Wenn man kompatibel zu verschieden Sprachen bleiben muß, steht overloading natürlich nicht zur Verfügung. Dann würde ich die Namen wie folgt wählen:

ReadBufferOfSizeFromFile(textBuf, TEXT_BUF_SIZE, inputFile); ReadBufferOfSizeFromFileWithFilter(textBuf, TEXT_BUF_SIZE, inputFile, ascciFilter); ReadBufferOfSizeFromString(textBuf, TEXT_BUF_SIZE, inputText); ReadBufferOfSizeFromStringWithFilter(textBuf, TEXT_BUF_SIZE, inputText, ascciFilter);

Ich würde sogar auf den Size-Parameter ganz verzichten wollen. Als Regel könnte man formulieren:

Alle Parameter die für eine Routine notwendig sind, werden nicht in den Name der Routine integriert, es sei denn, sie werden benötigt, die Aufgabe der Routine zu beschreiben.

Eine Routine muß mir immer die Frage beantworten (so kurz wie möglich, so Ausagekräftig wie nötig) was tu ich wenn ich "dich" benutze. Und "Was tust du? ReadBufferFromFileWithFilter." erklärt mir mehr als ein"Was tust du? FileReadBufferSizeFilter.". Sonst fängt man wieder an Kommentare zu schreiben. :-) hz

Ein FileReadBuffer (mit seinen Varianten) ergibt sich aus der Ähnlichkeit mit Funktionen wie FileDelete, FileGetXyz oder FileRetSize. Dafür spricht die ermöglichte Isomorphie (mit File f; f.readBuffer, f.getXyz, ...). Dafür spricht auch das Ziel der alphabetische Nähe ähnlicher Funktionen (alle Funktionen mit Files beginnen mit File...) welches die Einarbeitung in ein großes API sehr erleichtert. -- HelmutLeitner

FileReadBuffer ist ja noch okay. Die Argumente, das "File" vorne stehen soll, kann ich schon nachvollziehen (man sollte aber dann noch anmerken das copyStringBuffer unter diesem Gesichtspunkt Mist ist). Mich stört mehr, dass Funktionsvarianten einfach um den Namen der zusätzlichen Parameter ergänzt werden sollen. Die Namen die dabei entstehen können verwirrend sein. ReadBufferSize sollte eine Puffergrösse einlesen und nicht n-Bytes in einen Puffer. Ich finde den ProgrammierStilAlpha übrigens ganz gut (speziell bezogen auf seine Ansprüche). Eine theoretische Diskussion ist wahrscheinlich gar nicht sinnvoll. Besser wäre es konkrete Probleme bei der Namensvergabe im Projekt zu diskutieren und deren Ergebnisse als Beispiele oder Ausnahmen bei den entsprechenden Regeln zu hinterlegen. hz

• Obiger Zusatz ok?
• Das Problem ist, das, wenn man diesen Freiheitsgrad zuläßt, das System nicht mehr konsistent ist. Wenn ich dich richtig verstanden habe, spiegelt die Reihenfolge der Worte in den Namen die Reihenfolge der Funktionsargumente wider. Wenn das so ist, dann kann man bei einer Funktion mit dem Argument size das Wort Size nicht fortlassen, wenn auch eine andere Parametrisierung möglich ist, wie z.B. bei Strings, deren Länge durch das Endezeichen implizit ermittelt werden kann. Läßt man Verkürzungen in diesem Bereich zu, führt das meiner Meinung nach unweigerlich zu Ausnahmeregeln, wodurch ein solches Konstrukt unnötig kompliziert wird

• Gewisse Verkürzungen sind bei OO-Sprachen unausweichlich (bei Konstruktoren). Während eine prozedurale Sprache unterscheiden kann zwischen buffer=BufferNewSize(size) und buffer=BufferNewFileNa(filename), ist das bei Java-Konstruktoren nicht möglich: buffer=new Buffer(size) bzw. buffer=new Buffer(filename). Wenn es einem sympathisch ist, kann man aber solche prozeduralen Wrapper-Funktionen zusätzlich über die Konstruktoren "stülpen"!? [Was übrigens eine beliebte Methode ist um VirtuelleKonstruktoren? zu implementieren. Auf Request liefere ich eine Beschreibung nach (nicht jetzt, um 00:00 Ortszeit)]

• Ja, das entbehrt nicht einer gewissen Logik. Wäre die Funktion copyStringToBuffer(char *string, char *buffer) insoweit korrekt?
• copyStringToBufferSize wäre im Prinzip ok. Zwei klitzekleine Schönheitsfehler hat die Sache: (1) der Übergang von copyStringToBuffer zu String.copyToBuffer ist weiter (Zahl der geänderten Buchstaben) als bei einem äquivalenten StringGetBuffer(string,buffer) zu String.GetBuffer(buffer). (2) Die Harmonie zu neu interpretierten C-Funktionen wie strcpy, memcpy, memcmp als Verkürzungen von StrCpyStr(dest,source), MemCpyMem(...), MemCmpMem(...) ist nicht mehr so glatt erzielbar.
• Dann solltest du das drei Hauptpunkte weiter oben auch genau so erklären, da dieses Argument ohne Probleme nachvollziehbar ist. Dann kann auch diese kleine Diskussion und meine Frage wieder gelöscht werden :-)

• Ich habe damit keine Erfahrungen. Könntest du das auf separaten Seiten (wegen des Umfanges) kurz darstellen, vielleicht mit kleinen Beispielen, damit ich sehe, ob und wie ich mich auf diese Regel einstellen kann. Z.B. würde das ja bedeuten, dass die bestehenden WB3-Eingabe-HTML-Files nicht zulässig wären?

• Ich verstehe ungefähr, so du hinwillst, aber nicht genau genug. Sicher haben binäre Dateiformate einen Sinn, und Portabilität ist anzustreben, auch klar. Zielt diese Alignment-Regel nun auf eine Abstimmung von RAM-Alignment zu Datei-Alignment (einfaches Schreiben und Lesen), oder - wie mir scheint - auf eine bessere Lesbarkeit mit Sprachen, die eine Recordlänge bei Random-Access-Dateien verlangen (wie teilweise PASCAL oder BASIC)?
• Das Alignment, so wie du es beschreibst könnte Probleme machen, weil sich ein Array einer Struktur mit Elementen unterschiedlicher Länge sich u.U. überhaupt nicht konform in eine Datei schreiben ließe. Z.B.

struct { char string1[7]; char string2[11]; char string3[13]; };

Oder habe ich was mißverstanden?

• Eigentlich nicht. Eine Variable mit der obigen Struktur wäre 31 Byte groß und könnte direkt in eine Datei geschrieben werden. Mal ein praktisches Beispiel: Meine lexikalische Datei hat u.a. zwei zentrale Strukturen:

Kopf

typedef struct _HeaderOfLexicon { char version, release, OS, reserved1[13]; short numberOfTypes, numberOfAreas, maxTypesOfWord, reserved2[4]; unsigned short checkEndian; long beginOfLexicalEntries, numberOfWords, sizeOfDescription, reserved3[5]; } HeaderOfLexicon;

Datensatz

typedef struct _LexicalEntry { long index, /* start of the description */ attribute; /* bitfield for global attributes */ /* the values are not compressed yet ... */ short type, /* type of the lexical entry */ area, /* area of usage of the lexical entry */ numberOfCorrections; } LexicalEntry;

Die erste Struktur ist 64 Byte groß und beschreibt den Inhalt der lexikalischen Datei, die zweite Struktur ist 14 Byte groß und beschreibt die einzelnen Einträge in der lexikalischen Datei. Dazu kommen noch ein paar Blöcke mit den Worttypen, den Gebieten, den globalen Attributen und natürlich den Beschreibungen der Worte. Diese Daten werden genauso in die Datei geschrieben, wie sie im RAM vorliegen. Ferner können die Dateien entweder auf verschiedenen Rechnern lokal vorliegen oder aber auch auf einem zentralen Server, wo sie per NFS o. ä. in einem großen Netzwerk verfügbar wären.

Wenn diese Strukturen kein korrektes align hätten, gäbe es Probleme, mit unterschiedlichen Prozessoren zu arbeiten, da einige Prozessoren z.B. Langworte nur auf durch 4-teilbaren Adressen verwenden können, andere kommen mit geraden Adressen klar und wieder andere kommen mit jeder Adresse klar (ich weiß im Moment aber nicht genau, welche das sind).

• Die zweite Struktur kann aber von einer Größe von 14 Byte abweichen. Sie kann genausogut 16 Byte, 20 Byte oder 40 Byte groß sein (nur Beispiele, dir mir unmittelbar einfallen). Wobei ich mit "Byte" die EdvByte meine und nicht die CeeByte.
• Sorry, aber im Moment stehe ich etwas auf der Leitung: Wie kommst Du auf die unterschiedlichen Größen?
• Nur der Vollständigkeit: 16 Byte ergeben sich beim Auffüllen auf 4*N Byte (erlaubt). 20 Byte ergeben sich bei einem SL32-System. 40 Byte bei einem SL64-System.
• Tja, dann müssen wir wohl doch Typen mit eindeutigen Größen festlegen. Wären die Bezeichnungen u_int<Anzahl der Bits> und s_int<Anzahl der Bits> akzeptabel? Wie ist das mit Fließkommazahlen? Haben Mantisse und Exponent auch unterschiedliche Formate?
• Das ist jetzt sehr C-spezifisch. Die Frage ist, wo wir solche sprachspezifischen Festlegungen hingeben. Vermutlich ins Projekt?

• Weder Ralf noch ich haben vor, große "Schnitte" zu machen. Eher vielleicht die Löcher in den einzelnen Sprachen aufzufüllen. Außer den Exceptions und abstrakten Klassenhierarchien sehe ich eigentlich wenig Anlass. -- hl
• So in der Richtung. Später wird in den Richtlinen auch ein Abschnitt enthalten sein, wie man Eigenschaften einer Sprache in einer anderen 'emulieren' kann. Nur müssen dann mehrere Programmierer in diesem Projekt tätig sein, damit man diese Emulationen realisieren kann. Für nicht vorhandene oder unterschiedlich implementierte Funktionen, wie z.B. die RegularExpression könnten auch verschiedene Libraries für das Projekt zur Verfügung gestellt werden. Im Moment geht es eigentlich mehr darum, einen Ist-Zustand zu definieren, von dem man ausgehen kann (und natürlich auch, die bereits bestehende Software ohne große Reibungsverluste in das Projekt einzufügen).

Ein mittelfristiges Ziel von mir ist es z.B. auch, eine Beschreibungssprache für die Projekte zu definieren, analog zu einer GuiBeschreibungssprache, damit auch programmtechnisch relative unbedarfte, z.B. Linguisten, in der Lage sind, die eine oder andere Funktionalität zu implementieren oder auszuprobieren. --rae

1. Du wolltest eine Gui-Beschreibungssprache verwenden. Sollen dann für alle Sprachen passende Interpreter implementiert werden? Das allein ist ein Großprojekt.

• Das ist eine Regel, die Ralf eingebracht hat und die noch nicht ausdiskutiert ist. Wenn es möglich ist, das zu machen, könnte es sehr viel bringen, und es würde die zukunftsträchtige XML-Technologie im Projekt verankern. Einerseits ist sicher ein Riesenaufwand unvertretbar. Wenn es sich aber mit anderen Projekten koppeln läßt und Synergien abwirft, ist es nicht unrealistisch. Den WB3-Prototyp konnte ich auch nur realisieren, weil ich mich sowieso beruflich mit der CgiProgrammierung beschäftigen musste, also habe ich das am Beispile WB3 gelernt.
• Nicht unbedingt. Zur Internationalisierung von Software gibt es ja bereits diverse Konzepte (Peter könnte da sicher mehr dazu erzählen). Aber im Prinzip reicht es erst mal aus, die Oberflächen in einer Sprache zu entwerfen. Wie die Umsetzung in andere Sprachen dann stattfindet, könnte in Abhängigkeit zu den einzelnen Projekten entschieden werden. Ich z.B. habe geplant, den Translator selbst für die Übersetzung sorgen zu lassen, andere könnten mit einer Art Template arbeiten wie z.B. bei KDE, wieder andere könnten die Texte in Resource-Dateien mit einem Schlüsselwort ablegen (ich glaube, so wird/wurde das bei Windows gehandhabt), ... --rae

2. Java bräuchte z. B. Unterstützung für regular expressions. Es gibt zwar solche Bibliotheken, aber es müssen natürlich Wrapperfunktionen mit den passenden Namen gemäß dieses Standards geschrieben werden. In Perl müssen dann genauso Wrapperfunktionen mit gleichen Namen benutzt werden. Das führt letztlich dazu, daß ein Perl-Programmierer regexps nicht mehr auf die "natürliche Art" nutzen darf (irgendwas mit "=~" oder "s/.../.../" zum Beispiel).

• Ich glaube nicht, dass man das so eng sehen muss. Allerdings könnte es interessant sein, ähnliche Funktionalitäten in C oder Java zu haben. Wenn das dann z.B. so aussehen würde:

Perl: string =~ s/Maier/Müller/; Java: string.ReplaceRegex("/Maier/Müller/"); C: StringReplaceRegex(string,"/Maier/Müller/");

würde das in Perl nicht schaden, den anderen Sprachen nur gut tun. Es geht sicherlich nicht darum, mutwillig bürokratische, einengende Regeln zu erzeugen.

3. Java-Programmierer andererseits dürfen synchronized-Blöcke nicht mehr verwenden, weil es die in Basic nicht gibt usw ... -- mb

• Ich glaube nicht, dass es um solche Dinge je gehen wird. Wenn es Reibungspunkte gibt, dann wird man die diskutieren und gemeinsam die beste Lösung suchen. Vielleicht verwendet man dann solche Features oder auch nicht. Es ist aber wichtig, dass man sich in solchen Punkten abstimmt und die gegenseitigen Erfahrungen einholt.

Verschoben nach ExceptionsDiskussion

Zunächst sollte geklärt werden, ob diese Standards für die Programmierung von Bibliotheken (bzw. eines Servers) oder für front-ends verwendet werden soll. Es sollte da verschiedene Standards geben, das back-end wird wohl kaum mit Perl oder Basic programmiert, warum also darauf Rücksicht nehmen? -- mb

• Perl könnte am Server eine Rolle spielen (back-end), BASIC eher am Client (front-end). Warum sollten wir uns durch unterschiedliche Standards die Sache komplizierter machen? -- hl
• Weil die Sprachen zu sehr beschränkt werden und ihre Stärken nicht mehr ausspielen können, wenn zu sehr reglementiert wird. -- mb
• Das ist selbstverständlich ein wichtiger Aspekt. Allerdings stäubt sich bei mir einiges, wenn jemand sagt, diese Sprache ist nur für Frontends geeignet oder jene nur für Backends. Es sollte auch möglich sein, Front- und Backends in einem einzigen Prtogramm zu realisieren. --rae
• Du hast recht, ich möchte halt nur nicht die Sprachen bzw. Programmierer zu sehr einengen. Es sollte etwas weniger allgemeine Regeln geben, dafür einige sprachspezifische. --mb

• Mit letzerem hast du sicher recht, man kann APIs als Black-Box behandeln. Aber für alle Projektprogrammierer kann Konsistenz auf jeder Ebene nur ein Gewinn sein. Es kann leicht sein, dass zunächst ein API in C entsteht, das API oder die darunterliegende Logik später von jemand anderem in Java oder Perl verfügbar gemacht werden soll. Wir hoffen, dass bestimmte Regeln das erleichtern. -- hl
• Man kann vielleicht auf ein C-API ein Java-API draufsetzen. Aber warum sollte man eine Implementierung in einer Sprache in eine andere übersetzen? Am Ende arbeiten dann noch zwei Programmierer in zwei verschiedenen Sprachen nebeneinander an der gleichen Implementierung. Was soll das bringen?
• Vielleicht weil die entsprechende Sprache auf dem Zielsystem nicht unterstützt wird? --rae
• Schon, ich halte das aber eher für einen seltenen Spezialfall bzw. sollte das schon bei der Auswahl der Sprache abgeklärt werden. --mb
• Worauf beziehst Du dich im Moment? Auf die Sprache, die auf dem Zielsystem nicht vorhanden ist? Wenn ich die Zielrichtung des Projektes richtig in Erinnerung habe, sollen die Ergebnisse auch Web-Orientiert sein. Und daraus folgt, daß die Software zumindest teilweise auch auf embedded Systemen laufen sollte und dort sind die Möglichkeiten doch schon etwas eingeschränkt. --rae
• (Bin etwas mit der Einrückung durcheinandergekommen, sorry). Mit Embedded Systems kenn' ich mich nicht aus, deshalb rate ich hier mal:

Für die meisten "normalen" Systemen gibt es auch die "normalen" Sprachen, vor allem C und was darauf aufbaut. Wenn es das nicht gibt, liegt das meist an Einschränkungen, die dann auch den Programmierstil beeinflussen. Wenn z. B. der Speicherplatz für den Stack knapp ist, werden eher globale Variablen statt lokaler verwenden und die dann vielleicht auch noch mehrfach mit unterschiedlichen Bedeutungen. Also die ganzen Schweinereien :-) die in Standardcode sowieso nicht auftauchen dürfen.

Unser "Embedded-System-Hacker" könnte standardisierten Code vielleicht etwas besser lesen als nicht-standardisierten, letztlich wird er ihn aber größtenteils neu schreiben müssen, weil er die Standard-Konventionen nicht beachten kann. --mb

• Es kann doch leicht sein, dass eine zentrale Datenbank zunächst einmal eine C-Schnittstelle hat, auf von C oder Java oder Perl zugegriffen wird, um via CGI einen Client zu befriedigen, der wiederum in C, Java oder vielleicht BASIC (über C-DLL) auf diese Funktionen zugreift. Wer soll das über Jahre Stück für Stücke realisieren, wenn es nicht irgendwelche ordnenden Regeln gibt, die die Programmierung und Dokumentation vereinfachen.
• Alles, was zu einer API gehört und von weiten Teilen des Projekts gebraucht wird, muß selbstverständlich solchen Regeln gehorchen. Aber für die "Innereien" ist das eher störend. --mb
• Und an dieses Regeln hängen wir gerade. --rae

Das ganze wird ein Großprojekt, bei dem die meisten weder Lust noch Zeit haben werden, sich die Implementierung überhaupt näher anzusehen. -- mb

• Ich denke, dass jeder, der bei diesem Großprojekt mitmacht, natürlich auch die Regeln mitgestaltet. Es sollte keine Regeln geben, deren Sinnhaftigkeit nicht allgemein überzeugt. Was auf ProgrammierStilAlpha steht ist eine Diskussionsgrundlage, die erst einige Tage alt ist. Wir sind noch beim Sammeln und Ordnen. Klinke dich in die Diskussion ein, es wird das Konzept sicher besser machen!

• Binärdateien sollen auf jedem System lesbar sein, unabhängig davon, ob sie auf einem System mit little-endian oder mit big-endian erzeugt wurden (Ausnahme: Ausführbare Dateien). Wenn im Projekt nicht anders festgelegt, ist das Standardformat little-endian (wie Intel).
• kein Standard-Format, da sonst bei big-endian-Systemen ein unötiger Aufwand erzeugt wird.
• Willst du, wie beim TIF-Format, zwei unterschiedliche Formate, die durch ein Kennzeichen im Header auseinandergehalten werden? Das verdoppelt aber den Aufwand, weil jeder Leser mit beiden Formaten rechnen muss.
• Wie ist es denn bei TIF realisiert? Ich habe in jeder Datei einen Header mit einem 'magischen' Wort (meist affe). Beim Öffnen der Datei wird dieses Wort gelesen und, wenn es nicht 'affe' lautet, dies vermerkt (ich unterscheide nur zwischen eigenem und anderem Endian). Ist der Endian ein anderer, werden beim Lesen der Datensätze die betroffenen Elemente einfach konvertiert. Das ist zwar ein kleinen Overhead, der sollte aber aber nicht so sehr ins Gewicht fallen, da die Transfergeschwindigkeit von einem Massenspeicher eh begrenzt ist. Nachdem irgendwann mal die Datei wieder geschrieben wird, ist der Tausch nicht mehr nötig. --rae
• Auch innerhalb der ersten 4 Zeichen. Ich glaube, es wird 'II*\0' oder 'MM*\0' hineingeschrieben. Die Probleme des TIF-Format kommen aus vielen variablen und optionalen Teilen, der wahlweisen Verwendung verschiedener Datentypen, sowie Zeigern innerhalb des Files. Insgesamt ist es ein abstossendes Beispiel, wie so ein Problem eher nicht gelöst werden soll.

• Alignment bei Strukturen. Elemente von Strukturen, die in Dateien gespeichert werden, müssen an Speicheradressen beginnen, die der Bedingung

<Adresse des Elements> modulo <Größe des Elements> = 0

genügt. Lücken sind mit reservierten Elementen explizit aufzufüllen.

• Fragen siehe ProgrammierStilAlphaDiskussion#Alignment

http://www.ietf.org/rfc/rfc3072.txt

• Ich habe hier auch Probleme, weil ich viele Idiome benutze, bei denen "Ausgänge" verwendet werden, um die Verschachtelungstiefe und damit die Komplexität zu reduzieren. Z.B. Pseudocode

BEISPIEL_A: READ_LINES_OF_FILE { PROCESS_LINE ...(viele Zeilen) } BEISPIEL_B: READ_LINES_OF_FILE { IF_COMMENT { continue; } PROCESS_LINE ...(viele Zeilen) }

Für mich ist B ein lokal begrenzter, sehr schonender Eingriff, der A erweitert. Für andere ist es schlechter, fehleranfälliger Stil. Es gibt immer wieder ReligionsKriege um solche Fragen.

Nun, ReligionsKriege will ich nicht gerade entfesseln (dazu bin ich viel zu friedlich), sondern eher potentielle Gefahrenquellen aufzeigen (ich spreche da nur aus leidvoller Erfahrung :-/ ). Ich sehe eine entsprechende Einrücktiefe einfach als das kleinere Übel an. In Maßen eingesetzt sind diese Befehle durchaus sinnvoll --- leider arbeiten sehr viele Entwickler mit amerikanischen Tastaturen und verwechseln daher Maßen mit Massen.

Wie wäre es mit breaks, continues, vorzeitige Returns oder Exits sollten nur sehr sparsam verwendet und müssen auffällig kommentiert werden. Die Fehleranfälligkeit resultiert daraus, daß man in komplexen Bereichen so ein kleines break halt sehr leicht übersieht. Im übrigen sollten die Richtlinien so ähnlich gesehen werden wie deine erste Regel zur SoftwareOptimierung: Man sollte sich danach richten, aber wenn man genau weiß, was man tut, kann man ab und zu mal dagegen verstoßen. Gewisse Freiheitsgrade sollten schon möglich sein, aber das Ausnutzen sollte dann auch genau dokumentiert werden.

BEISPIEL_A: READ_LINES_OF_FILE { PROCESS_LINE ( data ) } BEISPIEL_B: READ_LINES_OF_FILE { IF_COMMENT { continue; } PROCESS_LINE ( data ) } BEISPIEL_C: READ_LINES_OF_FILE { ENTSCHEIDE ( ERSTER_BUCHSTABE ) { #: break 0-9: PROCESS_NUMBER ( data ) a-z: PROCESS_ALPHA ( data ) default: SYNTAX_ERROR } } BEISPIEL_D: bison/yacc