Codedesign

[Luckie]

Ich bekam jetzt mal Code zusehen, der meiner Meinung vom Design her schelcht war. Daraufhin habe ich ihn überarbeitet - eigentlich total omgekrempelt. Dabei habe ich mir einige Gedanken gemacht, was guten Code von schlechten unterscheidet. Als Essenz bin ich dabei auf folgende Regeln gekommen:

• Trennung von Aufgabe / Funktion und der Benutzerschnittstelle,
• erleichtert die Wiederverwendbarkeit von Codeteilen.
• Aufteilung in Teilprobleme. Daraus resultiert:
• Aufteilung in sinnvolle Abschnitte (Subroutinen).
• Für sich sprechende Variablen- und Funktionsnamen
• So wenig Kommentare wie möglich, so viele Kommentare wie nötig.
• So wenig globale Variablen wie möglich.
• Subroutinen sollten auf eine Bildschirmseite passen.

Jetzt würde ich von euch gerne wissen, ob ihr mit mit einer Meinung seit, ob ihr daran was auszustezten habt oder ob ihr aus eigenen erfahrungen noch was ergänzen würdet.

Anmerkunmg zum letzten Punkt: Diesen habe ich noch wie folgt erläuteret:

Zitat:

Über den letzten Punkt kann man geteilter Meinung sein. Was eigentlich schon damit anfängt, was eine Bildschirmseite denn ist. Bei einer Auflösung von 1280 x 1024 bekomme ich mehr auf eine Bildschirmseite als bei einer Auflösung von 800 x 600. Aber wie auch immer wir eine Bildschirmseite definieren, bin ich der Meinung, dass es das Lesen und Verstehen eines Quellcodes unheimlich erleichtert, wenn man die gesamte Subroutine mit einem Blick erfassen kann ohne großartig scrollen zu müssen. Hier zu kann man auch noch folgenden Punkt zu zählen: Zeilen sollten nicht länger als 80 Zeichen werden. Einmal, um horizontales Scrollen zu vermeiden, was erwiesenermaßen noch unbeliebter ist als vertikales, und zum Zweiten werden so meist, bei vernünftig gewählter Schriftgröße, hässliche Zeilenumbrüche beim Drucken vermieden.

[SirThornberry]

Grundsätzlich stimm ich den Punkten mal zu. Zum Thema subroutinen äußer ich mich lieber nich da ich sowas verabscheue, da sieht kein schwein mehr durch und in den meisten fällen würde es auch nicht schaden diese einfach in eine eigene funktion zu packen und diese dann in den privateteil zu packen.
Ich selbst programmier mehr nach dem Try and Error Prinzip und wenns dann bissl mehr source wird, wird umsortiert und zwischen den funktionen eine zeile {===} eingefügt damit man beim durchscrollen durch die unit schneller funktionsanfang und -ende findet... aber wer hier schonmal bissl source von mir runtergeladen hat der wird da in den seltensten fällen durchgesehen haben und wenns nach meinem scheff geht muss ich mich och mal dazu durchringen in der Zukunft kommentare im Source unterzubringen aber bins halt gewöhnt source von anderen durchzuwühlen um dann zu wissen wie was funktioniert...

So sind die Punkte eigentlich ne supi Grundlage für Open-Sourceprogrammierung und Projekte wo mehrere Leutz mitmachen

[Chewie]

Zitat von SirThornberry:

Zum Thema subroutinen äußer ich mich lieber nich da ich sowas verabscheue, da sieht kein schwein mehr durch und in den meisten fällen würde es auch nicht schaden diese einfach in eine eigene funktion zu packen und diese dann in den privateteil zu packen.

Hä? Subroutinen = Funktionen/Prozeduren.

[SirThornberry]

Achso, dachte mit Subroutinen waren die Proceduren/Funktionen gemeint die innerhalb einer Funktion definiert sind

[Daniel B]

Zitat von SirThornberry:

Achso, dachte mit Subroutinen waren die Proceduren/Funktionen gemeint die innerhalb einer Funktion definiert sind

Das sind eher Inlay-Prozeduren/Funktionen.

[SirThornberry]

ok, dann will ich mich halt zu den inlay-Prozeduren/Funktionen nicht weiter äußern (thx für die Theorie, war schon kurz davor nen thread dazu aufzumachen)

Der Punkt das "normale" proceduren und Funktionen nicht länger als eine Bildschirmseite sein sollten erscheint mir bissl unmöglich. Bei gewissen Projekten ist das einfach nicht möglich. Bsp.: 2D/3D-Move berechnungen. Außerdem kann man ja die übersichtlichkeit da waren in dem man wie schon erwähnt zwischen die Proceduren/Funktionen "{=======}" einfügt

[choose]

Hmmm. Jetzt wo ich das einmal runtergeschrieben habe, sind doch ein paar Fragen zum Design "dazwischengerutscht"... Trotzdem ist vieles zum Theme "Code" dabei. Was haltet ihr von dieser Ergänzung?

Klarer Entwurf

• Abstrakten Entwurf des Systems anfertigen (Modellierungswerkzeuge und Karten)
• Der Einsatz von DesignPatterns zahlt sich aus (auch ohne OOP lassen sich viele Ideen übertragen)
• Den Entwurf mit dritten diskutieren

Nutzung der Typenstrenge in Pascal/Delphi Language

• Typesierte Ordinalwerte, um "selbstüberprüfende" Routinen zu schreiben (unbedachte Fälle vom Compiler "aufspüren" lassen)
• Arbeiten mit Klassen und Interfaces statt mit interpretierten Integers und Records (implementierung später ändern, bessere Integration)

Kapselung, Geheimnisprinzip

• Wenn schon keine OOP, Funktionen nach Zuständigkeiten gliedern, nicht nach einfacherer Implementierung (UseCases)
• Trampdaten vermeiden (Delegation ok, aber es muss Sinn machen, dass eine Methode/Funktion einen Parameter erhält)
• Globale Variablen/Singeltons vermeiden (Probleme bei Nebenläufigkeit), stattdessen Kontexte verwenden

Vorbedingungen und Nachbedingungen

• Konsequener und wohldurchdachter Einsatz von Exceptions (auch hier: Typen!)
• Assertions, für Programmierung "By Contract"

Testen, Debugging, Profiling

• Code für Regressionstests und Unittests vorbereiten
• Logging nach Möglichkeit generieren und nicht implementieren (Konsistenz, Übersichtlichkeit)
• Instrumentieren von Code ausschließlich über Generatoren vornehmen lassen (Übersichtlichkeit)!

Es ist nichts schlimmes, die Lösung in mehreren Iterationen zu verbessern. Auch hier ist die Hilfe dritter unbezahlbar!

[phlux]

Irgendwo habe ich mal gelesen das Sakura zitiert hat, dass Prozeduren mit cirka 70 Zeilen länge am wenigsten Fehler enthalten, deshalb versuche ich persönlich zusatzfunktionen nicht umfangreich zu gestalten und wenn auf mehrere Funktionen aufzuteilen.
Ansonsten empfehle ich den OP Style Guide (gibts bei Luckie auf der Page ). Was ich ansonsten überhaupt nicht abkann (was man hier auch manchmal im Forum sieht) sind PERMANENTE GROSSSCHREIBUNG, so Spaghetticode, und nicht schön abgestufter Code . Naja das wars von meiner Seite zu dem Thema

mfg phlux

[Chewie]

Zitat von SirThornberry:

Achso, dachte mit Subroutinen waren die Proceduren/Funktionen gemeint die innerhalb einer Funktion definiert sind

Man sieht, dass du nie ein Perl-Programm gesehen hast

[negaH]

und das diese Inlay funktionen offiziell "nested" Funktionen heissen

Ich persönlich sehe nested Funktionen als guten OOP Stil an. Sie sind nämlich meistens nur 3-4 Zeilen lang und fassen Funktionalität zusammen die mehrmalig im übergeordneten Code benötigt wird, und zwar ausschließlich NUR im übergeordneten Code. Sobald diese Funktionalität interessant für andere Funktionen wird sollte man sie auslagern.

Nested Funktion sind deshalb auch übersichtlicher ! Denn man wird sie einmalig lesen und verstehen, und konzentiert sich dann auf den eigentlichen Code der natürlich nun viel kürzer und besser lesbar ist !

Wird nun die eigentliche Funktion kopiert, weil man sie eventuell wo anders einmalig benötigt, so kopiert man immer auch die neseted Funktionen mit. Somit verliert man nicht eventuell kurze Codestücken, oder muß diese aus anderen Units zusammen suchen.

Sie pauschal zu verdammen oder immer als gut zu heissen ist sehr schlechter "OOP/NOP" Stil !

Gruß Hagen