Welchen Codestil werden wir für die Assembler und C-Dateien nehmen? Ich bin dafür, dass wir uns auf einen möglichst einheitlichen Stil einigen, damit der Code gut lesbar und wartbar bleibt.
Für Assembler würde ich vorschlagen, dass Instruktionen mit einem Tab eingerückt werden. Labels werden nicht eingerückt. Dadurch heben sich Labels sofort sichtbar von den Instruktionen ab und die Struktur des Codes ist gut sichtbar. Außerdem sollten Doppelpunkte hinter Labels Pflicht sein, es sei denn es folgt ein db, dw oder ähnliches. Zeilenumbrüche vor Labels und zusammenhängenden Codeabschnitten können die Lesbarkeit noch verbessern, aber strecken bei übermäßigen Einsatz auch die Länge des Codes deutlich.
Beispiel
label1:
mov eax, foo
sub [bar], eax
label2:
or eax, eax
jnz label1
foo db "Foo Bar", 13, 10, 0Das wars eigentlich schon speziell zu Assembler, was mir so einfällt. Fangen wir also mit dem wohl strittigsten Punkt bei der C Formatierung an: Dem Einrücken und dem Setzen von Klammern. Ich halte folgendes für sinnvoll: (ist glaub ich Kernighan&Richie Style)
- Immer einrücken mit 1 Tab (im Editor sollte es auf 4 Zeichen eingestellt sein)
- Hinter einer geöffneten, geschwungenen Klammer ("{") folgt ein Zeilenumbruch und es wird eine weitere ebene tiefer eingerückt.
- eine Einrückstufe zurück vor einer geschlossenen, geschwungenen Klammer ("}")
- geschwungene öffnende Klammern bei Funktionensdeklarationen immer auf die nächste Zeile
- geschwungene öffnende Klammern nach if, for, while, etc immer auf die selbe Zeile.
Beispiel:
void tuwas(char *arg);
int main(int argc, char **argv)
{
int i;
for(i = 0; i < argc; i++) {
tuwas(argv[i]);
}
}
void tuwas(char *arg)
{
char *foo, *bar;
if(arg != NULL) {
if(arg[0] == '-') {
/* ... */
} else if(arg[0] == '/') {
/* ... */
} else {
/* ... */
}
}
}Auch hinter einem einzeiligen if, for, while usw, kommen immer geschwungene Klammern. Aber ich denke bei sehr kurzen {}-Blöcken ist es auch sinnvoll den komplett auf die Selbe Zeile wie die if-Abfrage zu schreiben.
if(arg == NULL) { doSomething(); }Im Beispiel habe ich die Pointer-Sternchen auch schon direkt an den Variablennamen geschrieben. Eigentlich gehört der Pointer zum Typ, aber es ist eine fiese Falle, wenn man schreibt:
char* foo, bar;und glaubt foo und bar wären beide jeweils Pointer. Deswegen gewöhne
ich mir an * und & immer an den Variablennamen.
Wobei es am einfachsten so ist:
char * foo;
char * bar;Dann können solche Fehler nicht passieren und die Position des * ist eigentlich egal.
Kommentare sollten C-Style Kommentare sein: Also /* ... */, aber ich denke wir haben alle Compiler, die nicht noch aus dem kalten Krieg stammen, also sollten C++-Style //-Kommentare auch völlig ok sein.
Sonst noch was allgemeines zu beiden Sprachen: (Die Beispiel lasse ich einfach mal in C, wobei sie auch in ASM zutreffen sollten.)
Hinter Kommata und Semikolons ein Leerzeichen, davor keins, wie auch in der deutschen Sprache üblich. Vor und hinter +, -, *, /, %, |, &, ||, &&, <<, !=, !, ~, = usw immer ein Leerzeichen, außer wenn +, -, ~ der ! ein Vorzeichen sind (oder * oder & als Pointer verwendet werden.) Hinter einer öffnenden Klammer und vor einer schließenden Klammer kein Leerzeichen.
int foo = !bar;
int foo = -1;
int foo = bar * ((49 + foobar[i] + quux) % 100);
int foo = &bar;
int foo = *bar;Nicht sofort eindeutige vorrangigkeiten von Rechenoperationen sollten wegen der besseren Lesbarkeit mit Klammern verdeutlicht werden.
Nicht so gut:
int foo = bar << foobar & mask; /* was wird zuerst ausgeführt? der shift oder die &-operation? */Besser:
int foo = bar << (foobar & mask); /* so ist es eindeutig */Konstanten und Makros immer in Großbuchstaben schreiben.
// C:
#define KERNEL_LOAD_ADDRESS 0x10000
; NASM-Syntax:
%define KERNEL_LOAD_ADDRESS 0x10000
; oder
KERNEL_LOAD_ADDRESS equ 0x10000
Wir müssen nicht unbedingt mit Tab arbeiten um einzurücken, aber es ist einfach sinnvoller, weil dann das Einrücken konsistent ist. (Kein Leerzeichen zählen. Außerdem ist Speicherschonend
.) Wer sein Tab auf 8 Zeichen eingestellt hat und sich darüber aufregt, dass bereit nach 4 Tabs der Code schon über den rechten Bildschirmrand hinausragt, sollte seine Editoreinstellungen korrigieren. (Oder auf meinen Lieblingseditor
Code::Blocks umsteigen.
)
Ich hoffe mal ich hab das Wichtigste genannt. Auf jedenfall hab ich mich nicht grad kurz gefasst.
Die Vorschläge basieren alle auf meinem persönlichen Stil und ich halte sie somit für das non-plus-ultra
Das muss aber nicht mit eurer Meinung übereinstimmen und deswegen denke ich, wir sollten uns schnell auf einen Stil einigen, damit dadurch nicht die eigentliche Programmierung aufgehalten wird. Ich bin auch bereit mich an eure Code-Stile anzupassen, sofern sie denn sinnvoll sind und sich alle dran halten.
Wenn wir uns geeinigt haben, ist dies sicherlich aus was, das man ins Wiki übertragen sollte.
Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
Drucken
Thema: Codestil (Gelesen 26899 mal)