Amiga ISO Collection

home *** CD-ROM | disk | FTP | other *** search

/ Amiga ISO Collection / AmigaDemoCD2.iso / ASCII / TEXTE / SCENE / FAQ-LISTS / cfaq_8.txt < prev next >

Wrap

Text File | 1995-01-03 | 23.1 KB | 520 lines

_______________ _____ _____ _________ ___________________ \. /________ |. /_____:o | /. \/|___/_ \ / \___ _____/|. / \|| /|. |: |// ______/·|. / ______ \ ___/ /. /_/· || / \: \|| |· |/ / \ \/ || /_______ \/+ / // ____/ || \ \ \ \: ¯¯¯ | / / / || \ /·\ / \ __/_ // / // |+ \ \ \ \___/ | \___/ / |· \/ \/ / / /· / \\ / \ / |: | / / / / \___/ \________/_____|\___/: |_____|_______/\________/_______/______/ l_____|·MBB· _ ___ \ _ ___|__________/\______\//\________________________________________________ _ \___ / ___/ \_____\//\______________ /\ ______/ _______/ ___ _ | _/ \ _ \_ \/ | ___)_/_ ___/_/_ ___)_\______ \______ | \ \/ / || | \ | \ | \ / / / _ __| \__________/____|| |____ |__ |__ _____/ ___ _ `----' `-----' `------' `------' `---------' `------' [hOMELESS÷bBS!] [bIRDHOUSE^pROJECTS eUROPEAN hQ][mYTH! gERMAN hQ][aRT-cORE! fUN hQ] [sYSdOODE: -sLIME!^bIRDHOUSE÷pROJECTS-lEADER^mYTH!] [cOdOODES: mOGUe!/sCX^aC! pRIMUS!/bP!-lEADER] [MR.VAiN/bNZ^aC! wHIRLWIND/mYTH!] [uPLOADER:GeNeRaTioN ][oF:[+] PRODIGY '95 [+]] [uPLOAD tIME:13:54:20][uPLOAD dATE:03-Jan-95] _ ___ \ _ ___|__________/\______\//\________________________________________________ _ \___ / ___/ \_____\//\______________ /\ ______/ _______/ ___ _ | _/ \ _ \_ \/ | ___)_/_ ___/_/_ ___)_\______ \______ | \ \/ / || | \ | \ | \ / / / _ __| \__________/____|| |____ |__ |__ _____/ ___ _ `----' `-----' `------' `------' `---------' `------' «------------------[ eLITE gUYS wILL gET iNVITED hERE ]------------------» . . . . : · . ____/¦__ ___/¦____ __/¦___________/¦__ ¦ ¦___/¦__ ! _ ____ \__\____ _// _____\_________ \ | | ____ \__ _:/\__ /· |____//· | \\_____ ·\| | | \\| |/· |____/ \ Oo / // | \ | \ l \\ | | ·\_ // | \ /_--_\ \__________\________/________/___j___j / \__________\ :\/ -------------------------------------l____/ :----------- ¡ · · . : · . . . . ! _ ____/¦__ ¦ ¦____¦\____ ____/¦__ ___/¦____ __/¦_____ __ _:/\__ _ _ ____ \__| |______ \ _ ____ \__\_ | _// _____ __ _ \ Oo / /· |____/| |/· __ __/ /· |____//· | \\_____ ·\ /_--_\ // | \| // | \_// | \ l \ l \\ :\/ \__________\ \____j /\__________\________/________/ ¡ -----------· :----l____/------------------------------- · · <*> pRODIGY gHQ <*> nEUTRON wHQ <*> iLLUSION eHQ <*> dYNAMIX gHQ <*> Upload Date: [01-03-95] «» Upload Time: [07:18:35] «-------------------[ aSK eLITE fOR SYS-PW & NUMBA ! ]-------------------» .__ _ r : __tHIS fILE wAS D/L fROM I _ _02-Jan-95_________________________: N _| \/ | G \/ T¾R¾S¾I LEADER H¾Q \\ ² tRISTAR & rED \ sECTOR ö . |_/\________/\__.___ _/\_______ | W /\ |\ ._ \ \ \ ____)² iNC. . \/\------------|/ |/____/ \ / __)__!---------------. |\/ / ² / | \ \ 4nODEZ | | \_____| \_____²_____/___________/ !_ |ö | | /_/\ | _/\__.___ !/\_._/\________/\________/\______! _/\______ \_\/ | \ \ \___!\ ._ \ ._ \ ____) \ . \ | 00:14:08 \ / |/ |/ / |/ / __)__ / | \_/¹ / | \ | / / / / \ | \ \_____²_____/____²_________/_________/___________/_____²_____/ö2Fö ² ² _!/\__ |__ \ Oo / +49 p¾R¾I¾V¾A¾T¾E¾! ___| / eLITE gUYS /_--_\ \ // wILL gET ²\/ tHE hOLY mASTER iS \/| iNVITED hERE ! mClOUD ² ² aND hIS hELPING hAND iS mARIO : : ¾ aSK fOR nUMBER aND sYSPW/nUP @BEGIN_FILE_ID.DIZFREQUENTLY ASKED QUESTIONS ABOUT `C` -German Edition- 8-10 @END_FILE_ID.DIZ /Teil 8/ Kapitel 7 Programmieren Mit dem Thema "Programmieren" bewegen wir uns relativ weit weg vom eigentlichen Thema dieser FAQ, der Programmiersprache C. Doch was nützt das schönste Werkzeug, wenn es an den Grundkenntnissen darüber mangelt, wie man dieses Werkzeug einsetzt? Natürlich können und wollen wir in dieser FAQ keinen in sich geschlossenen und vollständigen Überblick über das geben, was Programmieren ausmacht. Dazu ist das Thema zu umfangreich, umfaßt oder berührt es doch Gebiete wie Software-"Engineering", Arbeitsmethodik, Psychologie, formale Ausbildung/Qualifikation, Talent, Abstraktionsvermögen usw. Wir haben einfach ein paar Fragen aufgegriffen, die häufiger im Raum standen und diese aus unserer Sicht beantwortet. Dabei basieren unsere Antworten auf langjähriger einschlägiger Berufserfahrung. Die Antworten sind als Anregung gedacht, um in die Materie einzutauchen. (tw) Q7.1 Was ist guter Programmierstil? Was ist lesbare Programmierung? Betrachten wir als "Programmierstil" die äußere Form der Pro- gramme, gehen wir also davon aus, daß die Programme selber korrekt sind, der Stil also nur ihre Wirkung auf Menschen, nicht auf den Compiler betrifft, dann ist diese Frage sehr leicht zu beantworten. Ein Programmierstil ist gut, wenn er lesbare Programme erzeugt: Programme, die sowohl der Autor als auch andere Leute leicht verstehen, nachvollziehen, warten und modifizieren können. Womit wir bei der Frage wären, was lesbarer Programmierstil ist. Unverzichtbar für lesbare Programme sind: - Ausführliche Dokumentation. Jede Funktion braucht einen Kopfkommentar, in dem detailliert beschrieben ist, was die Funktion macht, welche Parameter sie erwartet, wie sie auf verschiedene Parameter reagiert, welche Werte sie zurückgibt, auf welche globalen Daten sie sich verläßt, welche globalen Daten sie verändert, von welchen Voraussetzungen sie ausgeht usw. Es muß möglich sein, die Funktion zu benutzen, ohne ihren Code selbst lesen zu müssen. Im Idealfall muß es möglich sein, den Code der Funktion zu 48 Programmieren --------------------------------------------------------------- löschen und sie anhand der Dokumentation neuzuschreiben, ohne daß sich für das Programm eine Beeinträchtigung ergibt. Die Dokumentation der ANSI-Standard-Library- Funktionen ist ein gutes Beispiel dafür, wie es sein sollte. - Ausführliche und sinnvolle Kommentare. Ein Kommentar wie a++; /* a inkrementieren */ ist zwar ausführlich, aber nicht sinnvoll. Hingegen kann /* Dateien schliessen */ fclose(in_fp); fclose(out_fp); fclose(err_fp); durchaus sinnvoll sein, wenn man Kommentare als Überschriften von Code-Abschnitten versteht. Es ist eine gute Praxis, alle Parameter und Variablen zu kommentieren. - Ein durchgängiger Klammerungs- und Einrückstil. Es gibt viele Stile, z.B. den als "One True Bracing Style" bekannt gewordenen, von K&R verwendeten Stil: while(a > b) { fct(a); a++; } oder die Version mit den Klammern in jeweils einer eigenen Zeile: while(a > b) { fct(a); a++; } wobei die Klammern wahlweise vollständig oder zur Hälfte mit eingerückt werden. Die Einrückung selber beträgt oft eine Tabulatorweite (8 Zeichen; leicht zu tippen, aber braucht viel Platz und breite Bildschirme) oder 2 oder 4 Zeichen. Welchen Stil man verwendet, ist eigentlich egal, wichtig ist nur, daß man ihn konsequent verwendet. Wenn man Programme modifiziert, sollte man dabei den Stil beibehalten, in dem das Programm geschrieben ist, auch wenn es nicht der persönliche Lieblingsstil ist. - Sprechende Funktions- und Variablennamen. Eine Zeile wie durchschnitt = summe / anzahl; ist wesentlich besser lesbar als Programmieren 49 --------------------------------------------------------------- d = s / n; und kann auch verstanden werden, wenn man nicht den ganzen Rest des Programms gelesen hat. Es hilft auch nicht viel, wenn irgendwo weit oben im Programm double d; /* berechneter Durchschnittswert */ steht. Der Name einer Variablen oder Funktion sollte ihrer Bedeutung angemessen sein. Es ist verwirrend, wenn einfache Zählvariablen als "laufvariable" oder "zaehler", wichtige global sichtbare Funktionen aber als "f" oder "cl1" o.ä. bezeichnet werden. - Klarer und strukturierter Programmaufbau. for(; a > 0; a = f(a)) { ... } und while(1) { if (a<=0) goto whileend; ... a = f(a); } whileend: tun beide dasselbe, die zweite Version wirkt aber eher verwirrend (vor allem wenn "..." mehrere Bildschirm- seiten lang ist). Große Programmteile sollte man in eigene Funktionen oder eigene Module verpacken. - Information Hiding. Informationen sollten immer nur so weit sichtbar sein, wie sie benötigt werden. Das bedeutet, daß man Hilfs- funktionen static definieren sollte (so daß sie nur in ihrem Modul sichtbar sind), Variablen möglichst im innersten Block definiert, in dem sie sichtbar sind, die Zugriffsalgorithmen für besondere Datenstrukturen in eigenen Modulen versteckt und nur über Funktionen auf diese Datenstrukturen zugreift usw. Allerdings gibt es bezüglich Programmierstil in C nur wenig, was wirklich unumstritten ist. Obwohl viele C-Programmierer die Möglichkeiten von C, Ausdrücke sehr knapp formulieren zu können, schätzen und benutzen, gibt es andere, die eine längere und ausführlichere Schreibweise vorziehen. Ob *p++ = c; besser oder schlechter lesbar ist als *p = c; p = p + 1; 50 Programmieren --------------------------------------------------------------- oder ob if (a==0) { x = 0; y = 1; } besserer Stil ist als if (a==0) x=0,y=1; oder ob for(;;) { c = getchar(); if (c==EOF) break; putchar(c); } leichter zu verstehen ist als while((c=getchar())!=EOF) putchar(c); (und ob ein break aus einer for-Schleife guter Stil ist) oder ob man lieber if (tolower(c)>='a' && tolower(c)<='m') putchar(c+13); else if (tolower(c)>='n' && tolower(c)<='z') putchar(c-13); else putchar(c); oder putchar((x=tolower(c))>='a'&&x<='m' ? c+13 : x>='n'&&x<='z' ? c-13 : c); schreiben sollte oder ob if (n==1) printf("%d file found\n",n); else printf("%d files found\n",n); wirklich besser ist als printf("%d file%s found\n", n, (n == 1) ? "" : "s"); oder gar printf("%d file%s found\n", n, "s" + (n == 1)); oder ob man die Klammern in Programmieren 51 --------------------------------------------------------------- c = *(p++); *(xptr->yptr->abc) = 0; a = ((b==0) || (c==0)); nicht lieber weglassen sollte oder ob man am Ende einer void- Funktion das (überflüssige) "return;" hinschreiben soll oder ob eine Funktion mehr als ein return haben darf oder ob der default-Zweig in einem switch() woanders als am Ende stehen darf oder ob man nach der sog. "Hungarian Notation" Datentypen in Variablen- und Funktionsnamen codieren soll, läßt sich nicht objektiv entscheiden. Jeder C-Programmierer wird nach seiner Gewohnheit und Einstellung das eine oder das andere bevorzugen - erfahrene und routinierte C-Programmierer eher die kürzeren, Neulinge oder eingeschworene Pascal-Programmierer eher die ausführlicheren Versionen. Diskussionen über solche Punkte haben ebensowenig Zweck wie darüber, ob ein S-Klasse-Mercedes besser als ein Fiat 125, ob Emacs besser als vi, ob Modula-2 besser als C oder C besser als C++ ist. (wr) Es gibt unumstößliche Wahrheiten: vi ist besser als Emacs, C ist besser als Modula-2, C++ ist besser als C und die Hungarian-Notation taugt einfach nichts. (tw) Q7.2 Wie werde ich ein guter C-Programmierer? Dafür zuerst eine Definition, was ein guter C-Programmierer ist: 1. Jemand, der C kennt: die Syntax, die Bedeutung der Schlüsselworte, den Aufbau von Ausdrücken und Statements, die verschiedenen Compiler-Phasen, die Arbeitsweise des Preprozessors, die Promotionsregeln, die Gültigkeits- und Sichtbarkeitsregeln, die Regeln der Pointerarithmetik, was definiert und undefiniert ist usw. 2. Jemand, der die Standard-Library kennt: die Funktionen, ihre Parameter, ihre Rückgabewerte, ihre Headerfiles. Wer glaubt, Stringoperationen in C seien mühsam oder kompliziert, kennt nicht die vielen mächtigen Stringfunktionen der Standard-Library. 3. Jemand, der Ahnung von Informatik hat: wie in jeder anderen Programmiersprache sind Kenntnisse über Algorithmen und Datenstrukturen unverzichtbar. Obwohl man als C-Programmierer nicht unbedingt den Unterschied zwischen Bubblesort und Heapsort kennen muß, sollte man schon wissen, wie man Datenstrukturen aufbaut, ob man Arrays, Listen oder Bäume verwendet, welche Vorteile Zustandsautomaten haben usw. 4. Jemand, der genug Erfahrung hat, um Programme strukturiert aufzubauen und sinnvolle Funktionsschnitt- stellen zu entwerfen. 52 Programmieren --------------------------------------------------------------- 5. Jemand, der weiß, wie man die vielen Möglichkeiten von C gebraucht, ohne sie zu mißbrauchen, und der dadurch lesbare und klare Programme schreibt. 6. Jemand, der in der Lage ist, komplizierte Dinge einfach zu implementieren. All dies zu erreichen ist nicht einfach und braucht eine Menge Zeit und Erfahrung. Für einen Anfänger ist es sehr zu emp- fehlen, seine C-Programme einem erfahrenen Programmierer vor- zulegen und sich erklären zu lassen, was man anders und besser hätte machen können. Wer hat nicht am Anfang Dinge wie for(i=0;i<strlen(string);i++) oder if (i==0) fct0(); else if (i==1) fct1(); else if (i==2) fct2(); else if (i==3) fct3(); else if (i==4) fct4(); else if (i==5) fct5(); else if (i==6) fct6(); else if (i==7) fct7(); else if (i==8) fct8(); else if (i==9) fct9(); else if (i==10) fct10(); oder char s[100]; while(fgets(s,100,filepointer)!=NULL) printf(s); gemacht? Dazu (oder genauer, dagegen) braucht man gute Literatur, z.B. K&R, die Rationale oder gleich den ANSI-C Standard, um zu lernen, was C "wirklich" ist. Viele Bücher mögen zwar als Tutorials besser geeignet sein, aber enthalten oft Fehler, Aus- lassungen oder Ungenauigkeiten, durch die man sich z.B. Dinge wie void main(int argc,char **argv,char **envp) angewöhnt. Desweiteren sollte man niemals aufhören, über den Programmier- stil, den man im Laufe der Zeit entwickelt, nachzudenken und ihn ggfs. anzupassen und zu verändern. Die Programme uner- fahrener Anfänger sind in den Augen von Profis oft er- schreckend, und jeder erfahrene C-Programmierer wird für seine ersten Programme nur Kopfschütteln übrighaben. (wr) Programmieren 53 --------------------------------------------------------------- /Ende von Teil 8/ Keep hacking Wolfram «------------------[ eLITE gUYS wILL gET iNVITED hERE ]------------------» . . . . : · . ____/¦__ ___/¦____ __/¦___________/¦__ ¦ ¦___/¦__ ! _ ____ \__\____ _// _____\_________ \ | | ____ \__ _:/\__ /· |____//· | \\_____ ·\| | | \\| |/· |____/ \ Oo / // | \ | \ l \\ | | ·\_ // | \ /_--_\ \__________\________/________/___j___j / \__________\ :\/ -------------------------------------l____/ :----------- ¡ · · . : · . . . . ! _ ____/¦__ ¦ ¦____¦\____ ____/¦__ ___/¦____ __/¦_____ __ _:/\__ _ _ ____ \__| |______ \ _ ____ \__\_ | _// _____ __ _ \ Oo / /· |____/| |/· __ __/ /· |____//· | \\_____ ·\ /_--_\ // | \| // | \_// | \ l \ l \\ :\/ \__________\ \____j /\__________\________/________/ ¡ -----------· :----l____/------------------------------- · · <*> pRODIGY gHQ <*> nEUTRON wHQ <*> iLLUSION eHQ <*> dYNAMIX gHQ <*> Upload Date: [01-03-95] «» Upload Time: [07:18:35] «-------------------[ aSK eLITE fOR SYS-PW & NUMBA ! ]-------------------» [-AquaAdder v1.0-] -sLiME!^bP·LEADER^mTH! mOGUe!^aC! pRIMUS!/bP·lEADER wHIRLWIND/mTH! MR.VAIN/BNZ^sXi^aC! -- --- ---- pHUKKIN' fAST aMIGA ^ wORLD'S lARGEST cHIPTUNE aREA ---- --- -- ____ ___| |_____________ __________________ ____________________________ _/ _| | ._________\/__________ \ _/___\______ \ _____/ _____/ \ \. | l/ / \/ | _____/_ l / _____/\____ _/\____ \_ \___| |________/____||-Mo!|________________/_______\ _______\ ________/ l____| l____| \/ \/ -- --- ---- aMI-eX fREE-lEECH ^ bIG aSCII bASE © bY aC! ---- --- -- -- mYTH! gHQ - -÷- - bIRDHOUSE pROJECTS! eHQ - -÷- - aRT-cORE! eHQ -- _______________ _____ _____ _________ ___________________ \. /________ |. /_____:o | /. \/|___/_ \ / \___ _____/|. / \|| /|. |: |// ______/·|. / ______ \ ___/ /. /_/· || / \: \|| |· |/ / \ \/ || /_______ \/+ / // ____/ || \ \ \ \: ¯¯¯ | / / / || \ /·\ / \ __/_ // / // |+ \ \ \ \___/ | \___/ / |· \/ \/ / / /· / \\ / \ / |: | / / / / \___/ \________/_____|\___/: |_____|_______/\________/_______/______/ l_____|·MBB·