Programmierdogmata

[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

[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

[Uwe Raabe]

Zitat von FBrust:

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.