guter stil????

[Der_Unwissende]

HI,
ich möchte hier nur der Vollständigkeit halber mal erwähnen, dass wohl eh jeder ein wenig seinen eigenen Stil hat. Das ist auch ganz gut so, sonst wäre die Vielfalt, die wie wir an Programmen haben wahrscheinlich sehr viel geringer.

Aber wichtig ist es überhaupt einen zu haben und den auch konsequent durchzusetzen. Es gibt dabei kein perfekt oder richtig, aber es gibt eine Menge falsch. So gehört (einhellige Meinung vieler Menschen die sich damit beschäftigt haben) zu einem guten Stil, dass man überflüssige Fehler einfach schon durch den Stil vermeidet. Dazu gehören insbesondere Kommentare und natürlich begin und end um Blöcke.
Genauso sollte es keine leeren except Abschnitte geben, wenn dann doch mal ein Fehler auftaucht...

Es gibt nette Bücher die sich mit dem Thema beschäftigen und auch wenn es nicht direkt Delphi ist, kann ich da "The Elements of Java Style" nur wärmstens empfehlen, die bringen in 108 Punkten eine Menge Erfahrung unter.

Das Wichtigste ist und bleibt aber, dass es nur Guides sind, es sind keine Vorschriften. Man profitiert davon sich an ihnen zu orientieren und in vielen Punkten lernt man sicherlich was dazu, aber man muss eben nicht alles übernehmen. Gerade für eine Firma ist es einfach wichtig, dass Code verstanden wird, egal von wem (also jetzt in der zuständigen Abteilung!). Hier ist es also wirklich wichtig, dass eben nicht jeder seinen Stil verfolgt, sondern einfach besser einen Stil fest zu schreiben, den dann aber jeder gleich lesen und verstehen kann. Über die einzelnen Punkte kann man dann immer noch streiten

Gruß Der Unwissende

[negaH]

Zitat:

Zitat von negaH:

4.) N. Wirth hat mit Absicht die "Gültigkeit eines Source Blocks" visuell grafisch auch als eingerückter Block mit einem senkrecht untereinander stehendem BEGIN und END eingeführt. Es ist also essentiell das BEGIN und END auf gleicher Einrückungsebene zu schreiben.

Ich finde, dass sich der Quelltext dadurch nur um eine weitere Zeile aufbläht. Logisch ist die genaue Einteilung mit begin/end ohnehin für Menschen nicht (IMO): Schließlich ist es ja egal, wie viele Anweisungen danach folgen (nach einer if-Bedingung zB), es muss nur dem Compiler genau gesagt werden.

Und genau das ist die falsche Sichtweise. Du versuchst die Anzahl an Zeilen zu optimieren statt sich darauf zu konzentrieren so viele Zeilen an Source zu schreiben wie es notwendig ist ein Problem auch deutlich und einfach verstehbar zu umschreiben. Deine Zielsetzung konzentiert sich auf ein Detail statt auf das gesammte Problem.

Zitat:

Zitat von negaH:

5.) was nun ? IstPrim() oder IsPrime() ? aber nicht IsPrim() das ist denglish.

Wenn du genau hinschaust, wirst du feststellen, dass ich IstPrim geschrieben habe.

Hä, hast du das editiert ? Ich kann mich erinnern das dort noch IsPrim() stand. Falls nicht, sorry, ändert aber nichts an der Aussage ansich Es bezieht sich ja nicht persönlich auf dich sondern gilt eher allgemein.

Zitat:

Zitat von negaH:

6.) in der Mathemtik ist es üblich N als Synonym für eine Natürlich Zahl zu betrachten, so wie R für rationelle Zahlen etc.pp.

Ich bin Programmierer und kein Mathematiker.

Doch bist du, sind wir alle.
Die Hardware basiert auf der Boolschen Algebra, und in der Programmierung ist es immer von Vorteil auch ein bischen Mathematik zu beherrschen.

Davon abgesehen versucht, bei unserem speziellen Problem, ein Programmierer ein rein mathematisches Problem in eine Software umzusetzen. Es ist aber fatal eine Sichtweise an den Tag zu legen die im Grunde ignorant ist. Denn deine Aussage heist für mich persönlich das du eine mathemtische Aufgabe nicht deshalb mathematisch korrekt angehen möchtest weil du sagt "na und, ich bin Programmierer und kein Mathematiker". Das ist ignorant und meiner Meinung nach eben auch ein "schlechter Programmierstil". Programmierstil bedeutet nicht wie der Souce aussieht, nein das ist nur eine Wirkung der Ursache. Und die Ursache für einen guten Programmierstil ist die Frage WIE der Programmierer ein Problem lösst. Und handelt es sich um ein Problem der Mathematik dann sollte er es auch so angehen. An Hand des Sources kann man also durchaus erkennen ob ein Programmierer sachlich fundiert und sauber ein Problem angegangen ist. Ist dies der Fall dann ist der Source sauber formatiert, folgt einer Logik, ist nachvollziehbar und umschreibt das zu lösende Problem auch für Andere verständlich. Ein Source ist dann nicht nur ein Source sondern quasi ein Lehrbuch das mit eigener Sprache ein Problem erklärt.

Zitat:

Zitat von negaH:

7.) Sonderfall 1 ist zu wenig und berücksicht eben nicht negative Zahlen

Hast du mir doch in 2.) schon gesagt?

Nicht nur. Ich meinte das man bei dieser schnellen "Eingangsüberprüfung" gleich nebenbei abprüfen kann

1.) ist Zahl ungerade ?
2.) ist Zahl größer 2 ?

Man schließt damit also implizit Zahlen aus die

1.) negativ sind
2.) gleich Null sind
3.) gleich Eins sind
4.) gleich dem Spezialfall der einzigsten gerade Primzahl 2 sind
5.) gerade Zahlen sind

Diese 5 Bedingungen werden mit

Result := Odd(N) and (N > 2);

abgefragt.

Zitat:

Zitat von negaH:

8.) die Berechnung in for X := 0 to Trunc(Sqrt(n)) ist zwar auf Grund des Delphi Compilers möglich sollte aber aus Sicht eines Standard PASCAL Codes vermieden werden. Unter Umständen, bei erweiterte PASCAL Dialekten mit einer for i to x step y Syntax ist nämlich x als Schleifenendebedingung dynamisch veränderbar.

Ich programmiere Delphi, kein Pascal.

Und wieder eine Form der Ignoranz. (ich würde sogar sagen Trotzigkeit).
Es sollte im Bestreben jedes Programmieres sein nicht mit Scheuklappen rumzurennen, sondern auch andere Programmiersprachen und deren Konzepte zu erlernen und zu beherrschen.

Zitat:

Zitat von negaH:

9.) wenn es geht sollte man immer auf unnötige Sprachkonstruke verzichten und statt dessen mit "mathematischen" Zuweisungen arbeiten.

Hast du dafür ein konkretes Beispiel?

Ja, das obige. Es enthält sogar 3 solcher Fälle:

Delphi-Quellcode:

 Result := Odd(N) and (N > 2); 
 Result := N mod Candidate <> 0;
 Result := N = 2;

statt

Delphi-Quellcode:

if Odd(N) then
  if N > 2 then Result := True
    else Result := False
  else Result := False;

if N mod Candidate = 0 then
begin
  Result := False;
  Exit;
end;

Das eine ist eine mathematische Sichtweise, Denkweise als Formel. Das andere ist eine rein Algortihmische, ja fast schon Maschinen-denkweise.

Denn wie du siehst, benutzt man quasi eine mathematische Formel für die Umschreibung eines Sachverhaltes so ergibt sich auch automatisch der Fall das man eben nicht mit Exit; arbeiten muß, sondern stattdessen eine Result Variable zuweist und diese sauber als Bedingung in der while do Schleife als Abbruchbedingung abfragt.

Zitat:

Zitat von negaH:

10.) wenn es geht exit/goto/continue vermeinden

Warum? Es ist doch die effizienteste Methode, hier aus der Schleife zu springen, oder sehe ich das falsch?

weil durch diese Anweisungen der aktuelle Programmblock irregulär verlassen oder weitergeführt wird.
Ein Exit zb. springt direkt aus dem aktuellen und hierarisch geschachtelten Programmblock und verlässt die komplette Funktion/Procedure. Exit zerstört also den grafisch hierarischen Source Aufbau, somit den Lesefluß eines anderen Programmieres und finally damit auch die Verständlichkeit.

Allerdings sehe ich diesen Punkt nicht allzu dramatisch, denn es gibt durchaus Fälle in denen ein goto/exit durchaus eine enorme Steigerung der Effizienz im erzeugten Code zur Folge hat.
Dies ist aber in unserem Beispiel eben nicht der Fall, ergo gibt es keine logische Begründung Exit noch zu verwenden.

Eines kann ich dir aber mit Sicherheit garantieren:
der Vorteil deines Exits ist so gering das es den Peformancevorteil meiner Funktion auf Grund der algorithmischen Verbesserungen unmeßbar gering ausfällt.

Zitat:

Zitat von negaH:

11.) man muß nur mit ungeraden Zahlen die Trialdivision durchführen. Da es aber in Delphi keine for i tox step y Schleife gibt müsste man sich behelfen mit for x := 2 to Trunc(Sqrt(N)) div 2 do und mit if N mod (i*2+1) = 0 arrbeiten, um eben den offensichtlichen mathematischen Erfordernissen gerecht zu werden. Es geht hier um Exaktheit in der Programmier Arbeit die man leistet. Allerdings ist eine solche Zähleschleife wesentlich schlechter zu verstehen als eine while Schleife. In deinem Falle testet deine Funktion die Zahl N doppelt so häufig als es nötig wäre, ergo Effizienzeinbußen.

Hmm, da kann' ich so spontan nicht zustimmen. Was ist zum Beispiel mit 8? Die Wurzel von 8 ist 2, das dann nochmal geteilt durch 2 ist 1 und deine Schleife würde gar nicht ausgeführt!

Siehst du: ein guter Programmierstil fördert die Verständlichkeit beim Lesen durch Andere.
Anscheinend habe ich da aber vollständig versagt sonst hättest du meine Source auch verstanden und erkannt das der Fall 8 = gerade Zahl garnicht, nein niemals garnicht never, in der while Schleife auftreten kann.

Wenn ich eine Funktion haben möchte die abfragt ob N eine Primzahl ist dann kann ich von vornherein mit Odd(N) 50% aller Zahlen sehr sehr effizient ausschließen, nämlich alle geraden Zahlen wie auch die 8.

Bei der eigentlichen Trialdivision werden also nur ungerade Zahlen überprüft. Auch da wiederum müssen wir nicht modulo jeder Zahl testen denn das minimal Set der Zahlen mit denen man Modulo testen muß sind alle Primzhalen bis Wurzel(N). Der Einfachheit halber nehmen wir alle ungeraden Zahlen, was 50% weniger ist als in deinem Falle, aber immer noch weit mehr als notwendig.

Gruß Hagen

[sECuRE]

Hi Hagen,

Zitat von negaH:

Und genau das ist die falsche Sichtweise. Du versuchst die Anzahl an Zeilen zu optimieren statt sich darauf zu konzentrieren so viele Zeilen an Source zu schreiben wie es notwendig ist ein Problem auch deutlich und einfach verstehbar zu umschreiben. Deine Zielsetzung konzentiert sich auf ein Detail statt auf das gesammte Problem.

Mit der schwindenen Anzahl an Zeilen erhöht sich die Anzahl selbiger, die auf meinen Bildschirm passen und somit auch meine Effizienz beim Arbeiten . Ich versuche nicht krampfhaft Zeilen zu optimieren, sondern dort, wo es für mich sinnvoll ist.

Zitat von negaH:

Hä, hast du das editiert ? Ich kann mich erinnern das dort noch IsPrim() stand. Falls nicht, sorry, ändert aber nichts an der Aussage ansich Es bezieht sich ja nicht persönlich auf dich sondern gilt eher allgemein.

Nein, hab' ich nicht editiert. Vielleicht kannst du aus dem Link meiner Signatur entnehmen, dass ich mich für die deutsche Sprache interessiere und daher auch vor Anglizismen erstmal zurückschrecke; mich erstmal frage, ob sich das nicht auch auf Deutsch genauso verständlich ausdrücken lässt.

Zitat von negaH:

Doch bist du, sind wir alle.
Die Hardware basiert auf der Boolschen Algebra, und in der Programmierung ist es immer von Vorteil auch ein bischen Mathematik zu beherrschen.

Nein, da muss ich dir widersprechen. Mathematiker sind nicht gleich Programmierer (ich sage nicht Informatiker!) und auch nicht umgekehrt, da die einzelnen Gebiete doch sehr unterschiedlich sind, gerade wenn es um komplexe Fälle geht. Ich sehe mich jedenfalls definitiv nicht als Mathematiker, davon hab' ich viel zu wenig Ahnung.

Zitat von negaH:

Davon abgesehen versucht, bei unserem speziellen Problem, ein Programmierer ein rein mathematisches Problem in eine Software umzusetzen. Es ist aber fatal eine Sichtweise an den Tag zu legen die im Grunde ignorant ist. Denn deine Aussage heist für mich persönlich das du eine mathemtische Aufgabe nicht deshalb mathematisch korrekt angehen möchtest weil du sagt "na und, ich bin Programmierer und kein Mathematiker". Das ist ignorant und meiner Meinung nach eben auch ein "schlechter Programmierstil". Programmierstil bedeutet nicht wie der Souce aussieht, nein das ist nur eine Wirkung der Ursache. Und die Ursache für einen guten Programmierstil ist die Frage WIE der Programmierer ein Problem lösst. Und handelt es sich um ein Problem der Mathematik dann sollte er es auch so angehen. An Hand des Sources kann man also durchaus erkennen ob ein Programmierer sachlich fundiert und sauber ein Problem angegangen ist. Ist dies der Fall dann ist der Source sauber formatiert, folgt einer Logik, ist nachvollziehbar und umschreibt das zu lösende Problem auch für Andere verständlich. Ein Source ist dann nicht nur ein Source sondern quasi ein Lehrbuch das mit eigener Sprache ein Problem erklärt.

Nun, ich möchte sie schon mathematisch korrekt angehen, ich sagte ja nicht, dass ich, weil ich kein Mathematiker bin, mir erlaube, einfach gewissenslos Fehler zu machen. Allerdings ist die Wahl der Variablennamen schon fast Geschmackssache und sollte meiner Meinung nach nicht unbedingt mathematischen Gepflogenheiten angepasst sein.

Zitat von negaH:

Nicht nur. Ich meinte das man bei dieser schnellen "Eingangsüberprüfung" gleich nebenbei abprüfen kann

1.) ist Zahl ungerade ?
2.) ist Zahl größer 2 ?

Man schließt damit also implizit Zahlen aus die

1.) negativ sind
2.) gleich Null sind
3.) gleich Eins sind
4.) gleich dem Spezialfall der einzigsten gerade Primzahl 2 sind
5.) gerade Zahlen sind

Diese 5 Bedingungen werden mit

Result := Odd(N) and (N > 2);

abgefragt.

OK, das wurde mir aus deinem Post vorher nicht klar.

Zitat von negaH:

Und wieder eine Form der Ignoranz. (ich würde sogar sagen Trotzigkeit).
Es sollte im Bestreben jedes Programmieres sein nicht mit Scheuklappen rumzurennen, sondern auch andere Programmiersprachen und deren Konzepte zu erlernen und zu beherrschen.

Ja, diesmal ist es Trotzigkeit. Ich muss mich in der Schule teilweise mit Turbopascal herumärgern und meine das wörtlich; was da alles fehlt, ist unglaublich, wenn man sich einmal an Delphi gewöhnt hat (dynamische Arrays, bequeme Klassen, Dateinamen größer 8.3 Zeichen (gut, das hat mehr mit der IDE zu tun und den damals üblichen Beschränkungen)). Als Ersatz für Turbopascal bin ich nun auf Freepascal umgestiegen und komme damit ziemlich gut klar, für mich fällt das auch unter Delphi Language, was man damit kompilieren kann. Daher sage ich, dass ich kein Pascal schreibe, da mein Quelltext ja meist nicht abwärtskompatibel ist.

Zitat von negaH:

Ja, das obige. Es enthält sogar 3 solcher Fälle:

Delphi-Quellcode:

 Result := Odd(N) and (N > 2); 
 Result := N mod Candidate <> 0;
 Result := N = 2;

statt

Delphi-Quellcode:

if Odd(N) then
  if N > 2 then Result := True
    else Result := False
  else Result := False;

if N mod Candidate = 0 then
begin
  Result := False;
  Exit;
end;

Das eine ist eine mathematische Sichtweise, Denkweise als Formel. Das andere ist eine rein Algortihmische, ja fast schon Maschinen-denkweise.

OK, das macht klar, was du meinst. Ich behaupte allerdings, dass ich das nicht so extrem gemacht habe in meinem Beispiel. Bei mehreren Result:=true/false-Zuweisungen hintereinander schrecke ich meist auf und denke mir: Das könnte doch auch in einer Zeile mit einer geschickten Bedingung erledigt werden .

Zitat von negaH:

weil durch diese Anweisungen der aktuelle Programmblock irregulär verlassen oder weitergeführt wird.
Ein Exit zb. springt direkt aus dem aktuellen und hierarisch geschachtelten Programmblock und verlässt die komplette Funktion/Procedure. Exit zerstört also den grafisch hierarischen Source Aufbau, somit den Lesefluß eines anderen Programmieres und finally damit auch die Verständlichkeit.

Genau das bezwecke ich doch. Meinetwegen könnte man das exit ja in rot markieren, wenn es denn so deutlich werden muss, dass hier aus der Funktion ausgestiegen wird . Jedoch halte ich Prüfungen nach der Schleife, ob man dann ab hier noch weiterarbeiten soll, sehr unsauber. In C gibt es break 2; beispielweise, damit steigt man aus der jetztigen und der übergeordneten Schleife aus. Sowas gibt es in Delphi meines Wissens nach nicht, wodurch sich exit für mich legitimiert.

Zitat von negaH:

Siehst du: ein guter Programmierstil fördert die Verständlichkeit beim Lesen durch Andere.
Anscheinend habe ich da aber vollständig versagt sonst hättest du meine Source auch verstanden und erkannt das der Fall 8 = gerade Zahl garnicht, nein niemals garnicht never, in der while Schleife auftreten kann.

Ja, das habe ich tatsächlich übersehen beziehungsweise unabhängig von deinem Punkt 8.) (war es doch, oder?) gesehen.

Ich sehe, dass man am Algorithmus selbst wohl noch ein bisschen 'was ändern kann, das auch der Performance ganz gut tut. Allerdings könnte sich der Threadersteller ja auch mal hier melden und bescheid sagen, ob er die ganzen Verbesserungen überhaupt benutzt oder ob er an so optimierten Funktionen interessiert ist.

cu

[negaH]

Zitat:

Mit der schwindenen Anzahl an Zeilen erhöht sich die Anzahl selbiger, die auf meinen Bildschirm passen und somit auch meine Effizienz beim Arbeiten . Ich versuche nicht krampfhaft Zeilen zu optimieren, sondern dort, wo es für mich sinnvoll ist.

Siehst du und da haben wir beide komplett gegensätzliche Ansichten.

Du kaufst dir einen 100 Zoll Monitor und quetscht deinen Source so eng wie möglich damit du soviel Source wie möglich auf einen Blick überblicken kannst.
Ich prophezeie dir jetzt das du irgendwan auf so komplexe Probleme stoßen wirst das selbst ein 1000 Zoll Monitor und die Schriftart Arial 6 nicht mehr helfen wird dein komplexes Problem zu überblicken !!
Das Schlimme an dieser Arbeitsweise ist das du eine Spirale damit in Gang gesetzt hast die ins Unendliche wächst und immer weniger effektiv die geforderten Ziele an dich erfüllen lässt.

Richtig wäre es das Problem dialektisch zu betrachten und Stück für Stück auf kleine Probleme zu reduzieren. Je mehr du auf diese Art&Weise das Gesamtproblem zerlegst desto größer und ausführlicher kann der Source für jedes der Teilprobleme werden. Also direkt umgekehrt proportional.

Dh. man baut seinen Source so auf das jedes Modul ein abgeschlossenes Teiulproblem lösst und man somit jedes Teilproblem unabhängig von den anderen separat verstehen und auch testen kann. Dann kombiniert man in einer hierarisch übergeordneten Source alle diese Module um dann das Gesamtproblem zu lösen.

Dies gilt bis hinab zum Aufbau jeder einzelnen Quelltextzeile, also auch die Frage ob das begin auf gleicher Zeile wie if then steht oder ob man versucht hat über die Syntax eines begin end; eine grafische Struktur per Einrückungen in den Source zu bekommen. Die gilt also auch dafür ob man formal Result := Odd(N) and (N > 2) schreibt oder das mit if then Abfragen mechanisch lösst.

Somit benötigt man garnicht mehr den Überblick über alle Source auf einmal. Denn man hat ja Top-Down oder Bottom-Up jedes abgeschlossene Teilstück der Source verstanden, verifiziert und getestet. In dem Moment ist gesichert das die IsPrime() Funktion zb. wirklch korrekt funktioniert und kann so deren Internas vergessen. Es reicht dann einfach IsPrime() in die Lösung des Gesamtproblemes zu integrieren. Quasi "Aus den Augen aus dem Sinn", es interessiert nicht mehr wie IsPrime() intern funktioniert.

Diese Arbeitsweise ist gewichtet hierarisch und benötigt nicht den Zwang alles auf einmal überblicken zu müssen/wollen, und ergo auch nicht den Zwang den Source wenn möglich in eine Zeile zu quetschen. Es ist die Grundlage dafür das man in einem Team arbeiten kann in dem man sich als Einzelner auch nur auf Teilprobleme konzentieren wird.

Und denoch, halte ich dein Argument für irrelevant, denn zähle doch mal die Anzahl an Zeilen deines Sources und meines Sources. Da exitiert kein Unterschied und denoch gibt es gravierende Unterschiede in den Punkten: algorithmische Effizienz, Performance als Program, Struktur im Source, logische Fehlerhaftigkeit.

Programmstil ist die Frage WIE wir programmieren, und da wir das mit unserem Hirn machen, also eine Frage des Denkens. Man kann also eben nicht einen bestimmten Schreibstil in einem Delphi/PASCAL Source lösslösen von der Frage ob derjenige Programmierer in der Lage ist ein Problem gedanklich zu durchdringen.

Trennt man dies so gibt es mehrere Möglichkeiten:

1.) der Programmierer durchdringt ein Problem logisch korekt kann es aber nicht in Source transportieren, weil er einen schlchten Stil hat
2.) der Programmierer hat einen schlechten, unübersichtlichen Stil und kann so ein Problem nicht von unten durchdringen.

Ergo: ein sauberer und gut struktuirerter Source ist gleichmaßen ein Indiz dafür das der Programmierer auch sein Denken logisch strukturieren kann, und finally ein Problemlöser ist.


Nochwas zur Dokumentation der Sourcen per Remarks, etc.pp:

Grundsätzlich widerspricht eine zusätzliche Beschreibung zu einem Source dem Sinn einer höheren Programmiersprache. Der Source sollte absolut selbsterklärend sein. Soweit das ideale Ziel einer idealen Programmiersprache. Aus Erfahrung kann ich aber bestätigen das gute Sources mit deutlich weniger Bemerkungen auskommmen, als schlechte Sourcen.

Es ist also ein Indiz für einen guten Programierstil wenn man mit weniger Remarks auskommt, oder gar mit keinen !
Es gibt kein Indiz dafür das man mit Remarks seinen Programmirstil tatsächlich verbessern würde.

Gruß Hagen

[Hansa]

Gutes Thema. Das ist echt wichtig und wirklich keine Ironie !! Habe nicht alles gelesen, aber einige Anmerkungen sind wohl erlaubt : als allererstes gilt es die Einrückungen tatsächlich zu machen. 2 Zeichen sind dazu IMHO optimal. Der Borland Style Guide beschreibt eigentlich alles recht gut. Bis auf eine Ausnahme : es wird vorgeschlagen, das begin eines Blocks in eigene Zeile zu setzen (wohlgemerkt in richtiger Einrückungstiefe !). Da bin ich anderer Meinung. Das zum end; irgendwo ein begin hingehört, das ist ja wohl klar. Nur gehört das zu einem if, else, while oder wozu jetzt Ich schreibe deshalb das begin in dieselbe Zeile, in der sie eingeleitet wird. Also in dieselbe, wo der Block beginnt.

Das nächste ist die Bezeichnung der Bezeichner, also Label93 + Co. 8) Dazu gibt es Hilfsmittel, z.B. GExperts. Dort kann man für jeden Typ den Prefix vorschlagen und braucht ihn nur zu ergänzen. Dazu wird man automatisch gezwungen, sofern er hinterlegt ist und kann die richtige Benennung nicht einfach vergessen !

Nächster Punkt : Exit, Break und auch Result. Ohje, goto taucht auch noch auf. Nur in Ausnahmefällen tatsächlich benutzen ! Es geht auch ohne.

Tja, soweit mein Senf. Allerdings fehlt da noch Inc und Dec. Wenn das bei heutigen Compilern überhaupt einen Vorteil bringt, dann ist es zumindest unleserlicher (i := i+1; ist wohl jedem klar) und wird wohl nur bei Programmen gebraucht, die zu 99,9 % nur am Hauptspeicher rumwerkeln.

[alcaeus]

Zitat von Hansa:

als allererstes gilt es die Einrückungen tatsächlich zu machen. 2 Zeichen sind dazu IMHO optimal.

Deiner Meinung nach schon, der Meinung manch anderes Programmierers nicht. Deshalb verwendet man normalerweise auch Tabs und setzt die Tabweite auf einen angenehmen Wert.
IMO ist das ein ziemlich grober Fehler im Styleguide

Greetz
alcaeus

[Hansa]

Alcaeus, es geht darum, überhaupt Einrückungen zu machen ! Schon mal Prozedur gehabt von 500 Zeilen ? Dann muß die Verschachtelungstiefe definitiv geklärt sein, denn sie wird automatisch sehr tief sein. Bei so was kann ich auch kein extra BEGIN in eigener Zeile gebrauchen, sonst sind es schnell 550 Zeilen usw. Deshalb mein einziger Einwand am Styleguide. Kommt eine Verschachtelungstiefe von 10 zustande, dann wäre das bei einer Lochkarten-Tab-Einstellung bereits 80 Einrückungsspaltem sprich 1 Sete weiter rechts gehts weiter. Somit käme mitetlfristig auch der Einsatz eines 1000 Spalten Monitors a la Hagen in Betracht. Lese mal einen Source, wo die Blöcke mit Tab=4 eingerückt sind : viel zu weit auseinandergezogen. Schlecht zu lesen. Es ist allerdings schwer nachzuvollziehen, wenn keinerlei Einrückungen gemacht werden. Selbst ein Blinder mit Krückstock merkt den Unterschied.

[Elvis]

Oh Mann, Hansa... du bist ja soo ein Held
Der Vorteil von Tabs ist, dass jeder sie so breit einstellen kann wie er will. Aber das dürfte den Horizont von Mr 500-Zeilen-Methode schon überschritten haben...

[Hansa]

Elvis lebt also immer noch ? Schön. Rest ist uninteressant und zudem OT.

[negaH]

Hey hey, keep cool Elvis. Du wirst unsachlich und persönlich.

Ich sehe es teils anders als Hansa:

strikt BEGIN auf eigener Zeile, BEGIN ist ein grafischer Anhaltspunkt so wie das IF THEN, WHILE DO, REPEAT usw. Sie gehören alle in eine eigene Zeile. Man liest doch mit den Augen, oder ? Ein BEGIN ist wie ein neuer Absatz in einem Brief. Man entfernt doch auch nicht die Absätze in einem Buch oder ? Und das vorherige IF THEN vor einem BEGIN Block ist doch nur die Überschrift für das neue Kapitel im Buch.

Die Länge oder Breite des Sources an Zeilen darf niemals dazu führen das wir einen Source auf Kosten der Verständlichkeit einschmelzen. Defakto gibt es keine Funktion oder Problem oder Aufgabenstellung die/das nicht kürzbar ist oder zerlegbar in weitere Unterfunktionen. Das gibt es einfach nicht.

Eine 500 zeilen Funktion ist ein ziemliches Monster und ich könnte mich nicht daran errinnern das ich in 15 Jahren Entwicklung so eine rießige Funktion jemals geschrieben habe. Sowas ist garnicht mehr durch einen Menchen überschaubau und durch-denk-bar. Ergo: 500 zeile für eine Funktion ist ein eindeutiges Indiz dafür das der Programmierer einen schlechten Stil hat. Er kann nämlich ein Problem nicht in Teilprobleme zerlegen, und das ist ja wohl die wichtigste Arbeit beim Programmieren.

Tabstops als Einrückungen: Ich hasse sie und ziehe 2 Leerzeichen wirklich vor. Das heist nicht das ich generell was gegen Tabstops hätte, sie wären eine gute Idee. Aber meine Erfahrungen haben mich gelehrt das ein Tabstop-Sourcecode leider sehr sehr oft eben eine Mixtur aus Leerzeichen-Einrückungen und Tabstops ist. Eine Verstellung eines 4 Zeichen Tabstopsources auf 2 Zeichen führte dann immer wieder dazu das denoch 4 Zeichen Leerzeichen Einrückungen im Source waren. Desweiteren verhalten sich Tabstops sehr sehr unterschiedlich je nachdem welchen Editor man benutzt. D.h. die Arbeistweise mit Tabstops hängt enorm auch vom Editor ab.

Wenn das alles wirklich einheitlich wäre, dann wären Tabstops auch eine sinnvolle Sache.
Und ich rede hier jetzt mal ganz allgemein von ganz verschiedenen Sprachen, sei es C, Assembler, Delphi/PASCAL (und Delphi ist immer noch PASCAL auch wenn Marketingstrategen anderer Meinung sind). Denn Einrückungen sind quasi fast in jeder Hochsprache ein grundlegendes Mittel zu besseren Strukturierung eines Sources.
Man wird mit den Einrückungen beim Delphi wesentlich weniger Probleme heutzutage haben also zb. beim einem WinWVR C Source Code. Und das liegt eben daran das Delphi Sourcen im Delphi-Editor geschrieben werden und dieser standardmäßig mit Leerzeichen statt Tabstops arbeitet. Ich ärgere mich immer wieder wenn ich einen fremden WinAVR C Source in die Hnde bekomme der Tabstops benutzt. Dort ist es nämlich durchaus üblich die erste Einrückung in einer Funktion mit 3 oder 4 Zeichen zu beginnen und jede weitere Einrück mit 2 oder 4 fortzusetzen. Man hat also je nach TabStop-Programmierer ständig anders formatierte Sourcen.

Gruß Hagen