Programmierdogmata

[Delphi-Laie]

Hallo Programmierfreunde!

Was ich jetzt erstelle, brennt mir schon seit Tagen unter den Nägeln, nun ist es wegen dieses Beitrages soweit.

Im Verlaufe meiner mehrjährigen Forumsaktivität stieß ich auf mehrere Grundsätze, die ich teilweise bis gar nicht nachvollziehen kann. Just fallen mir drei ein:

1. Die Verteufelung des GOTOs. Sog. Spaghetticode mag auch ich nicht, aber wenn er funktioniert, ist gegen ihn nur einzuwenden, daß er schwierig nachzuvollziehen ist. Wer es so gewohnt ist, wer so am besten denken kann und fehlerfreie Ergebnisse liefert, dem solle man das so machen lassen, vor allem, wenn er für sich selbst programmiert und die Quellcodes aus gutem Willen beilegt. Ein dosiertes Verwenden dieses Sprungbefehles kann Code kürzer, effizienter und schneller machen. Machen wir uns nichts vor: break und exit sind verkappte GOTOs, die all' die zufrieden- und ruhigstellen sollen, die das GOTO scheuen wie der Teufel das Weihwasser (ich nicht).

2. Die Ablehnung globaler Variablen. Auch, wenn man keine explizit formuliert, so gibt es diese jedoch in Form z.B. bei der VCL-Programmierung in Form der Formulare (hier zeigt sich übrigens, daß exakter Ausdruck notwendig ist, denn wie verständlich wäre wohl "in Form der Forms"?!). Wenn der Compiler globale Variablen akzeptiert und dabei nicht mal mit Hinweisen oder gar Warnungen daherkommt, was ist daran so verdammenswert?

3. Die Forderung, Oberfläche und Rechenteil zu trennen. Dauern Berechnungen länger, ist die Oberfläche bei nur einem VCL-Thread unbedienbar, dann kann ich diese Forderung nachvollziehen. Doch was ist mit der Speicherung? Warum z.B. soll man ein StringGrid neben der Darstellung nicht gleich auch noch für die Speicherung derselben Daten verwenden (mißbrauchen?), wenn es dafür doch grundsätzlich geeignet ist, insbesondere, wenn man nur mit Strings operiert (ansonsten kommen lästige Konvertierungen hinzu)? Speichert man die angezeigten Daten "extra", so erhöhen sich m.E. tendenziell Quellcode (Übersichtlichkeit!) und Compilatsgröße. Gerade bei meinen 1-Mann-Projekten und begrenzten Programmierfähigkeiten ist es wichtig, den/die Quellcode(s) möglichst kompakt zu halten.


Vielleicht fallen Euch noch mehr solcher Grundsatzforderungen ein, die auf mich in ihrer reinen Form, ich nenne es ganz deutlich, die Tendenz zum Dogma erkennen lassen.

Wie sind Eure Meinungen dazu?

Gruß Delphi-Laie

Ergänzung: 4. An der Strukturierung der Quelltexte (Einrückungen usw.) scheiden sich auch regelmäßig die Geister bis hin zu ideologischen Grabenkriegen.

[hoika]

Hallo,

Ich denke, dass du ein paar Tage zu spät drin bist !
Der 1. April ist bereits vorbei.


Heiko

[jfheins]

Nur kurz:

1. Übermäßiges benutzen von goto macht den Code schlechter lesbar. Das ist wie mit Asbest: Am Anfang klingt das nach ner tollen Idee, aber wenn man dann nach ein paar Jahren nochmal ran soll hat man den Salat. Als "dosiertes Verwenden" lasse ich hier vielleicht so ein goto auf 30000 Zeilen gelten. Und man tut sich selbst i.d.R. einen Bärendienst, weil das dann "Einwegcode" wird. Möchte man in nem Jahr nochmal etwas größeres dran ändern ist das Horror.

2. Im Grunde siehe oben. Macht den Code tendenziell schwerer nachzuvollziehen und geht somit in die Richtung "Heute spare ich 15min, kostet mich morgen 1h. Aber erst morgen!!"

3. Äh ja, sobald du was anderes als Strings hast? Gibt so Zahlen und so ;-) Auch wenn du lange Listen mit Daten hast und eine Art "Filterfunktion" anbringst: Du entfernst einfach alle Daten aus der Anzeige, die nicht mit dem Filter übereinstimmen. Aber ja, das ist auch wieder ne Frage wie komplex das Programm ist. Zudem wird das Testen und umwandeln einfacher: Die eine Funktionalität auch als Konsolenprogramm? Kein Problem: Funktion rüberkopieren und ein bisschen Eingabelogik in die Main-Function. Oh, ein Bug aufgetaucht? Einmal fixen, copy paste zurück. Ein Level weiter ist dann, dass sich beide Versionen Quelltextdateien teilen. und somit wirklich den gleichen Algorithmus benutzen.

Allgemein hat das also eher mit der Komplexität zu tun: Bei einfachen Programmen kann man sich auch leicht wieder reindenken. Bei großen Programmen geht das nicht so einfach, da spielt dann die Wartbarkeit eine tragende Rolle.

Zitat:

Gerade bei meinen 1-Mann-Projekten und begrenzten Programmierfähigkeiten ist es wichtig, den/die Quellcode(s) möglichst kompakt zu halten.

Sehe ich als Fehlschluss. Leerzeilen und sprechende Typnamen tragen wesentlich zum Verständnis bei. Lieber ein bisschen mehr in Funktionen aufteilen und eigene Klassen erstellen als LOC-Minimierung zu betreiben.

Hehe, ich habe mir gerade mal Codemetriken von VS generieren lassen, für mein aktuelles Projekt:

Zitat:

Projekt: SecretWorldDominiation
Bereich: Namespace
Namespace: SecretWorldDominiation
Wartbarkeitsindex: 82
Zyklomatische Komplexität: 354
Vererbungstiefe: 7
Klassenkopplung: 172
Codezeilen: 1.657

Die Zeilen sind auf 16 Dateien aufgeteilt. (Fast jeder Klasse wurde eine eigene Datei spendiert)
Jetzt bräuchte ich da nur noch Vergleichswerte :stupid:

[Daniel]

Alle 4 genannten Punkte wurden in (nicht nur) diesem Forum schon bis zum bitten Ende durchdiskutiert.

[FBrust]

Hallo,

da hat Daniel natürlich recht und die meisten Diskussionen verwandeln sich tatsächlich spätestens nach dem 5. Post in Glaubenskriege.

Man muss sich darüber im klaren sein, dass man, sofern man in einem Team arbeitet, den Code nicht für sich selbst, sondern immer für den nächsten Entwickler schreibt, der sich damit auseinandersetzeen muss (diese Erkenntnis stammt nicht von mir, ich stimme ihr aber zu). Insofern geht es m. E. weniger darum, ob Goto, Exit usw. Teufelszeug sind oder nicht, sondern dass klare Regeln existieren, an die sich alle halten.

Bei uns im Haus gibt es ein mehrseitiges Dokument, in dem möglichst genau (d. h. bis hin zu Einrückung und Groß/Kleinschreibung) festgelegt ist, wie Quelltext zu erstellen ist, welche Anweisungen zu verwenden sind (und welche nicht) und wie er auszusehen hat. Das Ergebnis ist von allen lesbarer und nachvollziehbarer Code.

Jeder muss natürlich für sich selbst entscheiden, ob das für ihn Sinn macht oder nicht (und als Einzelentwickler ist es vielleicht nicht so wichtig), aber wenn man im Team arbeitet, ist meiner Erfahrung nach ein solches Dokument eine enorm große Hilfe.


Gruß
Frank

[Furtbichler]

Hi, mein Senf:
Grundsätzlich kannst Du so schlampig programmieren, wie Du willst. Aber wenn Du dich stetig verbessern willst, dann schreib die besten und saubersten Programme der Welt.

1. Die Verteufelung des GOTOs. GOTO wird nie benötigt. Du kannst ein 'break', 'exit' oder 'return (xy)' verwenden. Und wenn man Clean-Code verfolgt, ist selbst ein 'break' unnötig.

2. Die Ablehnung globaler Variablen. Globale Variablen bedeuten, das Du faul bist und dir keine Gedanken über dein Systemdesign gemacht hast. Ganz ohne globale Variablen kommt man aber manchmal nicht aus. Allerdings sollte dein Bestreben sein, sie wen Möglich zu vermeiden. Die Gründe kannst Du im Netz und im Forum nachlesen. In modernen Sprachen sind die globalen Variablen/Singletons hinter statischen Klassen versteckt, was (fast) aufs Gleiche rauskommt, aber nicht so auffällt ;-)

3. Die Forderung, Oberfläche und Rechenteil zu trennen. Hiermit ist gemeint, das die Logik nicht hinter einem 'Button1_Click' ausprogrammiert werden sollte ("Trenne Funktion und Design").

4. Strukturierung der Quelltexte (Einrückungen usw.) Tu es einfach. Wenn mir das nicht gefällt, jage ich es durch meinen eigenen Formatierer und wir müssen uns darüber nicht streiten. Aber sorge Du dafür, das deine Einrückung konsistent und automatisierbar ist, denn ich hab keine Lust, mir dein Gemecker anzuhören, weil Du die Gleichheitszeichen immer in Spalte 39 haben willst und kein Formatierer der Welt das so für dich hinbekommt.

Zitat:

ich nenne es ganz deutlich, die Tendenz zum Dogma erkennen lassen.

Was ist für einen Newbie schlimm, sich an Dogmen (Mehrzahl von Dogma) zu halten? Diese Regeln (oder nenne es Dogmen, meine Güte) sind von Leuten erdacht, die 30+ Jahre programmieren und folglich die Essenz aus den Erfahrungen, die Du erst machen musst. Also: Partizipiere!

[SubData]

Ich muss meinen Vorrednern da einfach zustimmen.
Nur weil man etwas verwenden kann, heißt das noch lange nicht, dass man es verwenden muss.
Wenn man wirklich sauberen und durchdachten Code schreibt, dann sind Dinge wie globale Variablen, GOTOs, Do Withs, etc. völlig unnötig.

Naja, fast unnötig. Ich habe in den meisten meiner Anwendungen auch globale Variablen.
Allerdings beschränke ich die immer gerne auf folgende Definition

Delphi-Quellcode:

threadvar
  tv: TThreadVars;
var
  pv: TPublicVars;

Im 'tv' werden alle globalen Werte gespeichert, die für diesen Thread notwendig sind.
Zum Beispiel ein Pointer auf den aktuellen Indy-Thread, oder ggf. noch eine Benutzerreferenz.

Im 'pv' stehen Werte für die aktuelle Programmversion, der Anwendungspfad, der Logpfad, etc.

Somit reichen 2 globale Variablen, die intern eine Klasse oder ein Record sind aus, um diverse
Konfigurationsmöglichkeiten durch die ganze Anwendung zu schleifen.

[Uwe Raabe]

Zitat:

Zitat von FBrust (Beitrag 1210491)

dass man, sofern man in einem Team arbeitet, den Code nicht für sich selbst, sondern immer für den nächsten Entwickler schreibt,

Ich kann zwar nur für mich sprechen, aber ich bin heute nicht mehr der Entwickler, der ich z.B. noch vor zwei, fünf, zehn Jahren war, und ich muss mich heute mit meinem damaligen Code und den darin enthaltenen Unzulänglichkeiten herumschlagen. Oft ärgere ich mich, nicht schon früher die Erkenntnisse umgesetzt zu haben, die meine heutige Programmier-Basis bilden.

Also, der nächste Entwickler bist in den meisten Fällen du selbst. Es ist also in deinem eigenen Interesse, den Code so wartbar wie möglich zu gestalten.

Dabei ist es nicht wichtig, welche Codier-Regeln du verwendest - Hauptsache du verwendest überhaupt welche.

[Delphi-Laie]

Danke an alle!

Was ich nun doch herauslas: Kleines, also vereinzeltes Ausbrechen aus dieser Regelmenge ist also manchmal doch vorteilhaft. Und genau das ist nämlich auch mein Empfinden. Nur darum ging es mir.

Zitat:

Zitat von Furtbichler (Beitrag 1210492)

Was ist für einen Newbie schlimm

Falls Du mich meinst: Ich programmiere seit 25 Jahren (insofern nicht mehrjährig, sondern eher vieljährig). Wenn ich ein Neuling wäre, hätte ich mir über so etwas nie Gedanken gemacht, ich hätte diese Grundsätze noch nicht einmal bemerkt, geschweige denn, den Kopf dafür freigehabt, auch diese zu beherzigen, zu befolgen.

Zitat:

Zitat von Furtbichler (Beitrag 1210492)

, sich an Dogmen (Mehrzahl von Dogma) zu halten? Diese Regeln (oder nenne es Dogmen, meine Güte)

Ach Furtbichler, Dogma ist ein griechisches Wort. Auch wenn wir es eingedeutscht großschreiben, kannst man ihm nicht wenigstens ab und zu seine originale Pluralform belassen und die nicht gleich reflexhaft - und fehlerhaft - als falsch verdammen? Ich tue es. Bitte nicht schon wieder.

[Mathematiker]

Hallo,
bisher verfolge ich die Diskussion mit wachsendem Interesse und wollte mich eigentlich nicht äußern.
Aber:

Zitat:

Zitat von Furtbichler (Beitrag 1210492)

Globale Variablen bedeuten, das Du faul bist und dir keine Gedanken über dein Systemdesign gemacht hast.

Danke! :lol: Jetzt weiß ich endlich, dass ich faul bin.
Bitte den Umgangston etwas mäßigen! :evil:

Beste Grüße
Mathematiker