Autor Thema: Codestil  (Gelesen 21924 mal)

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« am: 29. April 2005, 16:18 »
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, 0


Das 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 :P 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.
Dieser Text wird unter jedem Beitrag angezeigt.

hannibal

  • Host
  • Beiträge: 400
    • Profil anzeigen
    • brainsware - the rock.
Gespeichert
« Antwort #1 am: 01. May 2005, 12:11 »
Zitat von: PorkChicken


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(); }

argh! bitte nicht. ich find das irgendwie bloedsinn hier extra klammern zu machen, wo man doch alles schon so aufschreiben kann:


if(x == y)
    y = ((x + y) * (x - y))/2;


ist meiner meinung nach weitaus uebersichtlicher als mit geschwungenen klammern und in einer zeile.

Zitat

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 :P 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.


sonst stimme ich dir absolut zu ;)
\\o
o//
\o/

Roshl

  • Beiträge: 1 128
    • Profil anzeigen
    • http://www.lowlevel.net.tc
Gespeichert
« Antwort #2 am: 01. May 2005, 12:15 »
man kanns auch übertreiben...
[schild=1]Wieder ein wertvoller(?) Beitrag von Roshl[/schild]

stultus

  • Beiträge: 486
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 01. May 2005, 14:42 »
stimme euch bis auf in einem punkt zu, die öffnende mengenklammer ( { ) gehört noch in die selbe zeile wie der zugehörige sprachteil, also
if (i == 5) {
  do_something();
}

sowie

void do_something(void) {
  // Nur ein Dummy
}

find ich noch übersichtlicher ;)
MSN: planetconquestdm@hotmail.de
ICQ: 190-084-185

... Wayne?

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 01. May 2005, 14:44 »
Zitat von: hannibal
argh! bitte nicht. ich find das irgendwie bloedsinn hier extra klammern zu machen, wo man doch alles schon so aufschreiben kann:


if(x == y)
    y = ((x + y) * (x - y))/2;

ok, meinetwegen
Dieser Text wird unter jedem Beitrag angezeigt.

DDR-RAM

  • Beiträge: 184
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 04. May 2005, 20:11 »
hab mich zwar (noch) nicht zum coden angemeldet, aber ich würde nach for, if, while immer ein Leerzeichen zwischen der öffnenden Klammer machen. Das mit den Pointern und dem Stern find ich andersherum schöner (wie gesagt gehört zum Typ und wer schreibt denn schon mehrere Pointer deklarationen auf eine Zeile?).

zu asm:
ich mach zwischen befehl und operanden entweder ein oder zwei tabs, damit's gleiche zeile ist, weiß nicht, ob du es erwähnt hast, sieht schöner aus.

MfG
DDR-RAM

TeeJay

  • Beiträge: 630
    • Profil anzeigen
    • http://www.jay-code.de
Gespeichert
« Antwort #6 am: 05. May 2005, 01:13 »
Ich muss da widersprechen:

for(;;)
{

}

Die geschweiften klammern gehören jeweils in eine Neue Zeile. Da hat man auf einen Blick (nämlich anfange einer Zeile) ob beide Klammer da sind und was sie einschliessen. Die erste Klammer gleich hinter das "for(;;)" zu setzen halte ich für das unübersichtlichste was sich jemand ausgedacht hat....
----------------------
Redakteur bei LowLevel

Another Stupid Coder

  • Beiträge: 749
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 05. May 2005, 09:02 »
Ich stimme TJ zu :)

T-Head

  • Beiträge: 157
    • Profil anzeigen
    • http://www.t-head.de.vu/
Gespeichert
« Antwort #8 am: 05. May 2005, 12:58 »
Hi,

ich bin da auch TJ's Meinung! So mach ichs auch immer und so hab ichs auch gelernt!  :wink:

DDR-RAM

  • Beiträge: 184
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 05. May 2005, 19:47 »
aber der Quellcode bläht sich ganz schön auf. Also bei if-Statements, würde ich trotzdem noch selbe Zeile nehmen.

Was ist eigentlich mit max. Zeichen pro Zeile? 120?

MfG
DDR-RAM

joachim_neu

  • Beiträge: 1 228
    • Profil anzeigen
    • http://www.joachim-neu.de
Gespeichert
« Antwort #10 am: 05. May 2005, 20:42 »
würds so machen, dass es nie mehr sind, als man auf den bildschirm bekommt. sonst wirds unübersichtlich...
http://www.joachim-neu.de | http://www.orbitalpirates.de | http://www.middleageworld.de

System: 256 RAM, GeForce 2 MX 400, AMD Athlon XP 1600+, Windows XP, 1x Diskette, 1x DVD-ROM, 1x CD-R(W) Brenner,...

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #11 am: 05. May 2005, 20:45 »
Ich empfehle 79 Zeichen je Zeile, da das die Standardbreite von allen
möglichen Standards ist (80 Zeichen, 1 zur Sicherheit weg).
Damit duerfte man auch mit nem VGA-Standardmonitor ohne Scrollen
noch ziemlich weit kommen :)

Svenska

DDR-RAM

  • Beiträge: 184
    • Profil anzeigen
Gespeichert
« Antwort #12 am: 05. May 2005, 21:09 »
80 sind find ich zu wenig, ich bearbeite kein Quelltext im 25*80 Zeilenmodus. ;)
120 ist Courier New, Schriftgröße 10 auf 1024*768.
Find ich eigentlich ok.
Nur wenn man noch irgendwelche anderen Fenster damit drin hat wird es knapp.

MfG
DDR-RAM

joachim_neu

  • Beiträge: 1 228
    • Profil anzeigen
    • http://www.joachim-neu.de
Gespeichert
« Antwort #13 am: 05. May 2005, 21:46 »
:D machma 100 und fertig :D
http://www.joachim-neu.de | http://www.orbitalpirates.de | http://www.middleageworld.de

System: 256 RAM, GeForce 2 MX 400, AMD Athlon XP 1600+, Windows XP, 1x Diskette, 1x DVD-ROM, 1x CD-R(W) Brenner,...

DDR-RAM

  • Beiträge: 184
    • Profil anzeigen
Gespeichert
« Antwort #14 am: 11. May 2005, 20:21 »
Wie sieht es eigentlich aus mit Namenskonventionen?
Da spielt ja wieder ein wenig, das Thema "C oder C++" mit rein,

Hiermal ne kleine Umfrage, mir fallen gerade nicht mehr sachen ein.
Ich hab mal meine Standardwerte mit x versehen, ist eigentlich sowie WinApi und MFC  :oops:

Ungarische Notation:
[ ] nicht festgelegt
[ ] ja immer
  • ja außer z.B. i

[ ] noch seltener
[ ] gar nicht

Präfixe (mehrfachauswahl möglich ^^):
[ ] nicht festgelegt
  • s_  für für static
  • g_  für für global

[ ] m_ für member von einfachen C-Structs
  • m_ für member von Klassen
  • t_   für template

[ ] a_   für Argument
[ ] p_   für Parameter
[ ] l_   für lokal

Schreibweisen:
Funktionen:
[ ] nicht festgelegt
  • Der erste Buchstabe von jedem Wort groß, der Rest klein, keine Bindestriche

[ ] alles klein, wahlweise Bindestriche zwischen den einzelnen Wörtern

Variablen:
[ ] nicht festgelegt
  • Der erste Buchstabe von jedem Wort groß, der Rest klein, keine Bindestriche, falls keine ungarische Notation, der erste Buchstabe klein

[ ] alles klein, wahlweise Bindestriche zwischen den einzelnen Wörtern

Typen:
[ ] nicht festgelegt
[ ] Der erste Buchstabe von jedem Wort groß, der Rest klein, keine Bindestriche
[ ] alles klein, wahlweise Bindestriche zwischen den einzelnen Wörtern mit _t suffix
  • alles groß, wahlweise Bindestriche zwischen den einzelnen Wörtern

[ ] alles groß, wahlweise Bindestriche zwischen den einzelnen Wörtern mit _T suffix

C-Strukturen:
[ ] nicht festgelegt
[ ] Der erste Buchstabe von jedem Wort groß, der Rest klein, keine Bindestriche
[ ] alles klein, wahlweise Bindestriche zwischen den einzelnen Wörtern
  • alles groß, wahlweise Bindestriche zwischen den einzelnen Wörtern


Klassen:
[ ] nicht festgelegt
  • Der erste Buchstabe von jedem Wort groß, der Rest klein, keine Bindestriche

[ ] alles klein, wahlweise Bindestriche zwischen den einzelnen Wörtern
[ ] alles groß, wahlweise Bindestriche zwischen den einzelnen Wörtern

Präfixbuchstabe für Klassen:
[ ] (kein)
  • C

[ ] K
[ ] G
[ ] x
[ ] X
[ ] T
[ ] (usw.)

Makros:
  • groß

[ ] klein

sagt mal wie ihr es so macht.
Achso, ich hab C++-Spezifik sicherheitshalber reingenommen.
Schlüsselwort struct wird nur für C-Structs verwendet, also solche, die keine Funktionen haben.

MfG
DDR-RAM

Damian

  • Beiträge: 100
    • Profil anzeigen
    • http://www.cosysda.de
Gespeichert
« Antwort #15 am: 31. March 2006, 21:22 »
Ich poste mal ein code beispiel wie meine code struktur ist.... bitte nicht lästern diese code ist mal aus ein kleine spielerei enstanden...

#include <iostream.h>
#include <string.h>
// Deklarations teil
const char* prog_name;
double prog_ver;


int show_my_tm()
{
cout << "\n"; // schönheits option
cout << "*******************************************************************\n";
cout << "* ######        #       ##           ## °       #       ##      # *\n";
cout << "* #     #      # #      # #         # # #      # #      # #     # *\n";
cout << "* #      #    #   #     #  #       #  # #     #   #     #  #    # *\n";
cout << "* #      #   #     #    #   #     #   # #    #     #    #   #   # *\n";
cout << "* #      #  #########   #    #   #    # #   #########   #    #  # *\n";
cout << "* #     #  #         #  #     # #     # #  #         #  #     # # *\n";
cout << "* ######  #           # #      #      # # #           # #      ## *\n";
cout << "*******************************************************************\n";

cout << "\n";

cout << "Herrzlich willkommen zu "<< prog_name << " ver. " << prog_ver << "\n";

cout << "\n"; // achönheits option
}

int passwort_eingabe()
{
int cPasswort;
cout << "Willkommen Damian\n";
cout << "Geben Sie Ihren passwort ein: \n";
cin >> cPasswort;
//cout << cPasswort;

//prüfungsteil
//
if (cPasswort != 622310364)
{
cout << "Passwort falsch\n";
exit(1);
}
else
{
cout << "Passwort richtig\n";
}

}

int main()
{
prog_ver = 1.03;
prog_name = "Damian module";
show_my_tm();
passwort_eingabe();
//weitere functionen();
}





hmm durch die forum formatierung ist meine code schlecht lesbar geworden
Habe mein eigenen Code syntax ;)
Und rechtschreibfehlern dürft ihr behalten.
if (user =="user"){Rechtschreibfehler_behalten();}elseif (user >= "moderator"){Rechtschreibfehlern_korrigieren();}

T0ast3r

  • Gast
Gespeichert
« Antwort #16 am: 01. April 2006, 11:12 »
hmm, über den codestil habe ich noch gar nicht nachgedacht, wobei es mehr sekundär sein sollte
natührlich soll nicht jeder "wild" herumprogrammieren dass man am ende nichts mehr nachvollziehen kann, jedoch will ich auch niemanden etwas vorschreiben

wir könnten es ja auch so machen das es coder gibt die den quelltext schreiben und "designer" (oder was auch immer) die den code überarbeiten, "formatieren", rechtschreibung, usw.

Termite

  • Beiträge: 239
    • Profil anzeigen
Gespeichert
« Antwort #17 am: 04. April 2006, 13:46 »
Hi

schaut euch mal indent von gnu an. ggf kann das euere probleme lösen. damit kann man code nach Vorgaben formatieren.

ps wie seiht es eigentlich mit TABS aus und der einrücktiefe?

was ist mit defines ? müssen die Werte geklammert werden oder nicht?

z.B.

#define MONITOR_WIDTH 800
#define LOG_MON 500
#define LOGO_WIDTH  MONITOR_WIDTH - LOG_MON

#define LOGO_SIZE LOGO_WIDTH * LOGO_HEIGHT * FARBTIEFE

Oder doch lieber so. da passieren weniger fehler ;)

#define MONITOR_WIDTH (800)
#define LOG_MON (500)
#define LOGO_WIDTH  (MONITOR_WIDTH - LOG_MON)

#define LOGO_SIZE (LOGO_WIDTH * LOGO_HEIGHT * FARBTIEFE)

Damian

  • Beiträge: 100
    • Profil anzeigen
    • http://www.cosysda.de
Gespeichert
« Antwort #18 am: 04. April 2006, 18:12 »
Zitat von: Termite
Hi



#define MONITOR_WIDTH (800)
#define LOG_MON (500)
#define LOGO_WIDTH  (MONITOR_WIDTH - LOG_MON)

#define LOGO_SIZE (LOGO_WIDTH * LOGO_HEIGHT * FARBTIEFE)


Ich würde es so machen ja
Habe mein eigenen Code syntax ;)
Und rechtschreibfehlern dürft ihr behalten.
if (user =="user"){Rechtschreibfehler_behalten();}elseif (user >= "moderator"){Rechtschreibfehlern_korrigieren();}

Coffee

  • Beiträge: 470
    • Profil anzeigen
Gespeichert
« Antwort #19 am: 04. April 2006, 18:14 »
^^^^^^^^^^^^^
||||||||||||||||||||||||
||||||||||||||||||||||||
||||||||||||||||||||||||

ich würd auch so machen

 

Einloggen