Nicht nur beim Einrücken und beim Aufbau stellt man fest, dass es verschiedene Wege gibt, etwas zu programmieren. Als Anfänger neigt man dazu, manches umständlicher zu machen als es sein muss, als Fortgeschrittener neigt man dazu, zu viel zu kürzen. Ein Klassiker bei Anfängern ist folgende Abfrage:
1 2 | if (zeug == true) { |
oder
1 2 | if (zeug == false) { |
Einfacher geht:
1 2 | if (zeug) { |
1 | var RGW = Math.round((((Math.pow(rRAD, 2) * Math.PI * Breite) - (Math.pow(rRID, 2) * Math.PI * Breite)) * Dichte) / 1000000 * 100) / 100; |
oder
1 2 | if (!zeug) { |
Das spart nicht nur Arbeit und damit Zeit, sondern wird auch allgemein so gehandhabt, kann also im Prinzip jeder Programmierer lesen. Die zweite Frage die sich stellt ist die, ob man die Klammern um die Abfrage mit schreibt oder nicht, schließlich würde
1 2 | if zeug { |
ebenso funktionieren. Es funktioniert sogar, wenn man mehrere Abfragen hintereinander bringt:
1 2 | if !zeug || 8 + 2 = 10 { |
Allerdings erkennt man hier vielleicht schon das Problem: Je mehr Abfragen es werden, umso unübersichtlicher wird es ohne die Verwendung von Klammern, auch wenn das obere Beispiel ein wenig schwachsinnig ist.
Bei Berechnungen im Code rate ich eher dazu ab, möglichst wenig zu kürzen.
1 | time = 60 * 60 * 24; |
oder
1 | time = 86400; |
Das Ergebnis ist genau gleich, aber wer weiß noch genau, woher die Zahl 86400 kam? Wer die Meinung vertritt, dass das Spiel dadurch einen Bruchteil einer Nanosekunde schneller ist und das ganz wichtig sei, sollte dahinter wenigstens einen Kommentar lassen, damit man versteht, was sich hinter der Zahl verbirgt. Das kann auch dann nicht schaden, wenn man die Berechnung ausschreibt. Zur Veranschaulichung eine Zeile aus einem JavaScript-Code von mir:
1 | var RGW = Math.round((((Math.pow(rRAD, 2) * Math.PI * Breite) - (Math.pow(rRID, 2) * Math.PI * Breite)) * Dichte) / 1000000 * 100) / 100; |
Unschwer zu erkennen sind zwei Dinge: die Rechnung lässt sich kürzen, aber auch ohne Kürzung lässt sich kaum nachvollziehen, was sich dahinter verbirgt. Einen Codekommentar gibt es dazu nicht, allerdings wird die Berechnung auf der Homepage mit einer anschaulichen Formel erklärt, was fast noch besser ist.
Wie ich oben bereits angedeutet habe, sind Kürzungen vor allem dann sinnvoll, wenn sie die Lesbarkeit des Codes verbessern und wenn sie üblichen Konventionen entsprechen. In solchen Fällen kann man auch Sachen in eine Zeile schrieben, vorausgesetzt, es erfüllt mindestens eine der beiden Bedingungen. Allerdings sollte man sich Kürzungen nicht angewöhnen, nur weil man es einmal bei jemand anderem gesehen hat. Bevor man Gefahr läuft sich etwas Schlechtes anzugewöhnen, sollte man sich umschauen, ob das andere ebenso tun, also ob diese Methode üblich ist.
Üblich, um nicht zu sagen Pflicht, ist die Verwendung von Schleifen. Wenn man Code mit einer Schleife verkürzen kann, sollte man das auch tun.
Ein streitbares GM-Element findet sich im Draw-Event wieder. Besonders bei der GUI werden an mehrere Stellen Schriften und Farben definiert und dann Texte erzeugt oder Elemente gezeichnet. Hier bietet es sich verlockend an, Elemente mit gleichen Farben und Schriften zu einem Block zusammen zu fassen, was einige Zeilen Code sparen und scheinbar die Übersicht verbessern kann. Diese Vorgehensweise funktioniert so lange gut, bis der Tag kommt an dem man den Code ändern will, weil einem einfällt, dass man bei einem GUI-Element doch eine andere Farbe und eine andere Schrift braucht. Dann beginnt man die Blöcke zu zerschneiden, was Arbeit macht und fehleranfällig ist. Hier ist es ratsam für jedes Element einen eigenen Abschnitt zu schaffen, bei dem die Farbe und die Schrift individuell bestimmt werden, auch wenn man fünf Mal hintereinander dieselbe Schrift und Farbe verwendet.
Kürzungen fallen meistens in den Bereich der Codeoptimierung. Wenn es tatsächlich Bedarf gibt den Code aus Performancegründen zu optimieren, sollte man dies erst am Ende machen und sich auf jeden Fall vom unoptimierten Code eine Kopie machen, ggf. als Kommentar vor oder nach dem optimierten Code. Wenn man Fehler sucht, ist die Fehlersuche dadurch meist um einiges angenehmer.
Copy & Paste
Copy & Paste sind Segen und Fluch zugleich. Ich bin mir nicht mehr sicher wann mir das gezeigt wurde oder ob ich das damals noch im DOS Editor selber heraus gefunden habe, aber an diesem Tag hat sich meine Einstellung der Welt ein wenig geändert. Ich bin mir ziemlich sicher, dass sich in diesem Augenblick der Himmel geöffnet und mein Gesicht ein Sonnenstrahl getroffen hat, welcher mich gen Himmel zog. Aber irgendwann war dieser Strahl aus und ich landete wieder auf dem harten Boden der Realität.
Einen Text, egal ob kurz oder lang, zu kopieren und einzufügen spart i.d.R. viel Arbeit. Da spielt es kaum eine Rolle ob wir in Excel, Word, in einer Mail oder in der Programmierung arbeiten. Der Fluch besteht vorwiegend aus zwei Punkten.
- Fehler werden mit kopiert und man merkt es nur selten und dann meist zu spät.
- Man lernt fast nichts außer dem Copy & Paste selbst.
Eigentlich ist Copy & Paste sehr gut dazu geeignet Fehler zu vermeiden. Man schreibt etwas einmal richtig und kann den Text dann so oft kopieren, bis einem die Finger abfaulen. Meistens klopft man aber schon den ersten Text schlampig ein und kopiert den Fehler ungelesen weiter. Und wenn man dann in einer Datenbank die Spalte “GoupName“ hat und diesen 1000mal im Code übernimmt, stellt man erst dann fest, dass da ein „r” fehlt, wenn man die Bezeichnung mal selbst tippt. Entweder lässt man den Fehler so oder man wendet wieder Zeit auf um jede falsche Bezeichnung zu korrigieren.
Wenn man Glück hat, kann man mit suchen und ersetzten den Schaden sehr schnell beheben, allerdings tauchen hier gleich mehrere Probleme auf. Wenn man, wie in PHP, von einzelnen Dateien spricht, die den Fehler enthalten, dann ist das noch eine halbwegs angenehme Sache. Wenn man aber im GM den ganzen Code suchen muss, ist das nicht mehr so lustig, vor allem dann nicht, wenn auch Ressourcen davon betroffen sind. Wenn man Glück hat, ist die falsche Bezeichnung individuell. Wenn man Pech hat, gibt es die falsche Bezeichnung auch in einer anderen Form, die aber richtig ist. Beispiel: Variable GroupName und Variable GroupNames. Irgendwann fällt einem auf, dass man im Code laufend durcheinander kommt und man entschließt sich, aus GroupName NameOfGroup zu machen. Wer das Problem schnell mit Suchen und Ersetzen lösen will, sollte sich für den Rest des Tages nichts vornehmen, vor allem wenn er vergisst, nach der Variable ein Leerzeichen zu verwenden, damit GroupNames nicht ebenfalls verwandelt wird.
Solltet ihr mal vor der Entscheidung stehen: korrigiert es immer gleich. Ein „das mache ich später” bedeutet zu 99,9999752%, dass es nie gemacht wird. Auch nicht, wenn man eine Engine schreibt und diese für ein weiteres Projekt verwendet.
Fast noch schlimmer als diese mehr oder weniger kleinen Fehler ist aber, dass der Lerneffekt gleich Null ist. Um das wenigstens ein bisschen zu kompensieren, sollte man die kopierte Passage noch einmal durchlesen um zu prüfen, ob man es wirklich verstanden hat. Das sollte man auf jeden Fall IMMER tun, wenn man sich mit irgendetwas nicht richtig auskennt, egal was man kopiert. Passagen aus einer Fremdsprache, Programmcode oder einen Abschnitt, der die interionische Wechselwirkung bei konzentrierten Flüssigkeiten beschreibt. IMMER!
Übrigens – und an dieser Stelle schweife ich etwas ab – sollte man sich auch gut überlegen, ob man für alles Tools einsetzt, die einem die Arbeit abnehmen oder ob man sich mal auf den Arsch setzt und den ganzen Mist selbst macht um zu verstehen, was da eigentlich passiert. Seit ich das erste Mal mit HTML Editoren gearbeitet habe, habe ich Tabellen, Formulare und so gut wie alles mit einem Editor zusammen geklickt und nur kleine Korrekturen per Hand vorgenommen, oder den Code formatiert. Ja, dass kann man auch machen wenn man keine Ahnung hat.
Das geht schnell, einfach und man hat sein Ziel erreicht. Aber sobald man tiefer eintaucht und zum Beispiel per for-Schleife eine Tabelle erzeugen muss, bringt einem der Editor-Kram nichts. Absolut nichts! Mit etwas Glück kennt man die einzelnen Tags aber wenn man diese per C&P oft genug kopiert hat, nicht einmal das.
C&P zu intensiv eingesetzt ist der dunkle Pfad. Wer diesen in Verbindung mit einfachen Baukästen in Kombination verwendet, kann auch tolle Sachen machen, hat aber am Ende nichts verstanden.
GM zeichnet sich vor allem durch das einfache D&D-System aus. Anfänger erzielen damit sehr schnell kleine Erfolge, aber das Problem ist dabei, dass man sich daran gewöhnt und auch versucht, komplexere Dinge damit zu realisieren. Auch hier kann ich nur raten, sich nach dem ersten D&D-Erfolg mit GML zu befassen, bevor man zu bequem wird.
Sehr interessantes Zeug hier 🙂