Hinweis: Dieser Artikel ist ein Beitrag zum ScienceBlogs Blog-Schreibwettbewerb 2015. Hinweise zum Ablauf des Bewerbs und wie ihr dabei Abstimmen könnt findet ihr hier. Informationen über die Autoren der Wettbewerbsbeiträge findet ihr jeweils am Ende der Artikel.
sb-wettbewerb
——————————————
Hello there.

Ich dachte ich könnte mal beim Blogschreibwettbewerb mitmachen indem ich Euch etwas über übersichtlichen Code erzähle. Ich versuche nicht allzu Fachspezifisch zu sein, sodass dieser Artikel auch für Nicht-Programmierer geeignet ist.
Ich bin ein Programmierer im 3. Lehrjahr von 4 und lebe in der Schweiz. In diesem Artikel werde ich eines meiner Programme als Beispiel nehmen. Es geht nicht um das Programm oder den Code an sich, ich könnte jedes andere Programm nehmen dass mir zur Verfügung steht. Das Programm ist in C# mit Visual Studio geschrieben.

Schauen wir uns erstmal an wie mein Programm aussieht:

programm

Das Programm sieht jetzt nicht allzu spektakulär aus, aber die Main File hat knapp 400 Zeilen, wo es schon sehr unübersichtlich werden kann.

Bevor ich anfange will ich noch mal kurz erklären warum man den Code eigentlich übersichtlich halten sollte. Es gibt für mich 3 Gründe dies zu tun:
– Wenn andere am Programm arbeiten (Egal ob man im Team arbeitet oder wenn man in den Ferien ist und jmd einen vertritt: Die Personen die sonst noch am Programm arbeiten müssen sich schnell mit Eurem Code zurecht finden)
– Wenn man selbst nach langer Zeit das Programm bearbeitet (Beispiele wären, wenn man aus den oben erwähnten Ferien kommt oder wenn man nach einer Pause an einer Erweiterung des Programms arbeitet)
– Um den Überblick zu erhalten (Nichts ist nerviger als in 400+ Zeilen unübersichtlichem Code herauszusuchen wo die Methode oder Schlaufe ist die man gerade braucht)

Ich habe schon im Team an Programmen gearbeitet. Kommentieren und übersichtlicher Code ist da sehr wichtig.

Jetzt zur Frage, wie hält man den Code übersichtlich?
Folgende Punkte sind für mich sehr wichtig:
-Strukturieren
-Je weniger Code desto besser
-Kommentieren
-Dokumentieren

Fangen wir mit dem Obersten Punkt an: Wenn man seinen Code gut strukturiert, zum Beispiel mit Abständen, ist er schon mal sehr Leserlich. Dies kann auch beim Schreiben von Texten hilfreich sein. Wie man sehen kann verwende ich auch viele (Evtl zu viele…) Abstände um diesen Artikel leserlicher zu machen. In meinen Augen liest sich nichts schwieriger als eine endlos grosse Textwand.
Ein Beispiel wie man mithilfe von Abständen den Code leserlicher machen kann ist wie ich meine Variablen strukturiert habe.
Kurz erklärt: Variablen sind Platzhalter für Zahlen, Text, Objekte, etc. Dies ist aber nicht so wichtig.
Kommen wir zum Bild:

variablen

Hier kann man erkennen dass ich die Variablen nach Ihrem Datentyp sortiert habe. Der Datentyp erklärt was in der Variable gespeichert ist. Int steht für Integer und beschreibt eine Zahl. String Beschreibt einen Text. Diese Datentypen existieren weil die Verschiedenen Typen verschieden viel Platz im Speicher brauchen. Auch die Operationen mit den Variablen unterscheiden sich je nach Datentyp. Auch sind einige Datentypen untereinander inkompatibel. Ich kann zwar Zwei Strings mithilfe von + (Sring c = (String) a + (String) B) miteinander verbinden und es ist auch möglich Ints mithilfe von + zu addieren aber ich kann nicht folgendes schreiben: Int c = (String) a + (Int) b. Dies würde einen Fehler verursachen.
Zurück zur Übersichtlichkeit:
Es ist viel einfacher die Gewünschte Variable zu finden, wenn die Variablen nach Datentyp sortiert sind.
Auch interessant sind die Namen der Variablen. Man sollte immer gute und selbsterklärende Namen verwenden oder Namen die Sinn ergeben.
Zum Beispiel ist der Name “i” typisch für eine Zählvariable, also weiss man schon dass “i” als Zähler verwendet wird.
Auch sollten die Namen innerhalb des Programms konsistent bleiben. Die Variablen flip, flop und flap sind alle booleans, die entweder true (wahr) oder false (falsch) sein können und werden innerhalb des Programms als eine Art Schalter verwendet. Würde ich eine vierte Variable namens flup erstellen, wäre es leicht zu erraten wofür ich diese Variable Verwenden würde.

1 / 2 / Auf einer Seite lesen

Kommentare (39)

  1. #1 Rex-Lii
    17. September 2015

    Ich abonniere mal die Kommentare 🙂

  2. #2 Sebastian M.
    17. September 2015

    Man sollte meinen das diese Regeln bei Programmierern Allgemeinwissen wären aber dann stolpert man immer wieder über Skripte die diese einfachen Regeln missachten – trotz Programmierrichtlinien usw.
    Ich pack das mal zum situationsbedingten Teilen in meine Favoriten 😉

  3. #3 etg
    17. September 2015

    Hi Rex-Lii,

    da fallen mir spontan ein paar Dinge ein bzw. auf. Erst einmal: Hut ab, ein so spezifisches Thema zu behandeln, ich fand den Text insgesamt gut, ab jetzt nur noch Kritik 😉

    1. wäre der Text leichter zu lesen, wenn nicht so viele Rechtschreib- und Grammatikfehler drin wären.

    2. verwendest Du deutsche und englische Variablennamen, das wäre einheitlich besser.

    3. benutzt Du englisches Englisch, (leider) hat sich amerikanisches Englisch größtenteils durchgesetzt, ich kann nur empfehlen, das auch zu verwenden (colour vs. color).

    4. ist der Artikel nur für Programmierer verständlich und hilfreich, was nicht schlimm ist, aber den Text etwas verändern würde, wenn man das im Hinterkopf behält (keine Erklärung, was eine Variable ist).

    5. finde ich es befremdlich, dass in frm_paint zwei Boxen als Parameter übergeben werden, statt entweder 1 Box oder einem Array/einer Liste von Boxen.

    6. habe ich die Erfahrung gemacht, dass Kommentare auf Englisch insgesamt besser helfen.

    Das soll jetzt nicht zu negativ klingen, nur für das nächste Mal 😉

    Gruß, Ekkart.

  4. #4 Rex-Lii
    17. September 2015

    Naja, ich denke richtige Programmierer kennen das schon. Ich wollte jetzt auch nicht zu tief in die Materie gehen. Könnte auch über State-Event-Diagramme odr Klassendiagramme schreiben oder über UML allgemein. Könnte ich nächstes Jahr machen.

    Ich bin mal gespannt wie dieser Artikel so ankommt.

  5. #5 Kalabint
    17. September 2015

    Hi, Vielen dank für diese nette Zusammenfassung, kann ich in Zukunft sicher gut gebrauchen.

    Mit diesen Tipps ist man denke ich sicher mal gut beraten, das andere wird sich (hoffentlich) durch Übung einstellen 😉

    Have a nice Day

    Kalabint

  6. #6 Rex-Lii
    17. September 2015

    @etg

    An sich hast du Recht, aber ich mache dieses Programm in meiner Ausbildung nur zum lernen, also muss es nicht ganz perfekt sein.
    Wie ich schon erwähnt habe, ist der Inhalt des Codes eigentlich egal. Es geht nicht darum dass die Kommentare auf Deutsch oder English sind oder wie ich eine Methode aufrufe sondern eher um das Prinzip dass man Kommentare schreibt oder Code in Methoden auslagert. Ich habe den Text nicht explizit für Programmierer geschrieben, sondern habe auch in betracht gezogen dass nicht-programmierer das lesen und daher habe ich einige (für Programmierer offensichtliche und bekannte) Dinge erklärt.

    Zu meinem Deutsch und English, naja, ich habe schon lange nicht mehr “kontrolliertes” Deutsch geschrieben, also zB in der Schule. Ich bin ja schon seit 4 Jahren nicht mehr dort und kommuniziere in der Freizeit meist auf English da ich im Internet viel unterwegs bin. Vorallem auch in der Englishen Szene auf Youtube. Auch schreibe ich als Gamer sehr viel english, da in Online spielen alle möglichen Sprachen zusammen gewürfelt sind.

    Tut mir Leid dass mein Deutsch also etwas gelitten hat darunter. Ich hoffe man versteht den Text trotzdem.

  7. #7 andreas f
    17. September 2015

    Hi, nur eine kleine Anmerkung: Beim Lesen der Überschrift dachte ich erst , dass es um einen Code namens “Übersichtlichkeit” geht, so wie in “Opel Vectra”. Es gibt einen wenig schmeichelhaften Ausdruck für ein Leerzeichen wie es im Titel steht.. 😉

    Ansonsten aber guter Artikel.

  8. #8 Rex-Lii
    17. September 2015

    Hmmmmm.
    Meine Antwort auf etg scheint sich zu verzögern.
    Da steht irgendwas mit moderierung. Ich nehme an das heisst Florian muss den Kommentar noch freigeben, oder?

  9. #9 Mibit
    Kufstein
    17. September 2015

    Bei den Methodennamen graut es mir. Ein Tipp an den Author “Clean Code” von Robert C. Martin. Das ist DAS Buch für ProgrammiererInnen, oder solche die es werden wollen.

  10. #10 Moss the TeXie
    Ladenburg
    17. September 2015

    Hier kann man erkennen dass ich die Variablen nach Ihrem Datentyp sortiert habe.

    Kann man machen, erscheint mir aber nicht per se sinnvoll. Sowas sortiere ich eher nach semantischer bzw. logischer Funktion; in Deinem Fall wäre da z. B. die Zeile „private List<PictureBox> …“, die ich lieber direkt vor die drei „private PictureBox …“ als zu den anderen „private List…“ gestellt hätte.

    Andererseits zähle ich als fast auschließlicher /(pdf|Lua)(La)?TeX/-Hacker vermutlich nicht als richtiger Programmierer. 😉

  11. #11 Rex-Lii
    17. September 2015

    @Mibit

    Clean Code habe ich dieses Lehrjahr in der Schule.
    Modul 133. Da haben wir zwar Webentwicklung vorallem mit Java-Script, JQuery und nachher auch PHP, aber im Lehrplan steht was über Clean Code. Leider bin ich ja noch in der Ausbildung und kenne nicht alle Richtlinien :/

  12. #12 Rex-Lii
    17. September 2015

    @Moss the TeXie

    Naja, mir “richtige Programmierer” meine ich eher Leute vom Fach (die es gelernt haben zB via Ausbildung o.ä.) oder Leute die generell gut programmieren können.
    Ich meinte das in keinsterweise ab- oder bewertend.
    Ich meinte es eher so, dass die die sich auskennen meine Text lächerlich banal finden würden.

    Im grossen und ganzen hat da jeder auch seinen eigenen Stil, wie man die Variabled sortiert. Allerdings habe ich keine Ahnung was die Norm ist.

    @alle anderen
    Danke für die netten worte und Danke für das Feedback.

  13. #13 Benni
    17. September 2015
  14. #14 Polygon
    17. September 2015

    An dieser Stelle empfehle ich, den Code von Doom 3 anzuschauen. So wird es gut gemacht (z.B. https://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code).
    Ansonsten ein netter Artikel, der aber ruhig ein wenig tiefer in die Materie einsteigen kann. Wie lange ist objektorientierter Code übersichtlich (anchmal muss man sich durch 10 Klassen angeln, bis man den Code, der wirklich etwas tut, gefunden hat 😉 oder wie sollten Kommentare aussehen (z.B. sollten Kommentare nicht vor jeder kleinen Schleife offensichtliche Sachen erklären) oder wie benennt man Variablen (ich mag CamelCase).
    Zu “Je weniger Code, desto besser”: Nicht generell. Ich kann iterativen Code auf Teufel komm raus rekursiv gestalten und so einige Zeilen einsparen (nicht immer, aber gefühlt häufig). Nur dann hapert es mit dem Verständnis. Ähnlich sieht es mit Code aus, der zu viel in eine Zeile packen will oder aussieht wie in Quake (https://en.wikipedia.org/wiki/Fast_inverse_square_root). Wo ich gerade von einer Zeile rede: Bitte ersetzt Tabs durch Leerzeichen im Editor. Viel zu häufig schmeißen Tabs bei unterschiedlichen Editoren einiges durcheinander. Und pro Zeile sollten es auch nur maximal 80 Zeichen sein. Die 80 Zeichen haben zwar historische Gründe, aber wenn man heute mehrere Fenster nebeneinander aufmacht oder im vertikalen Bildschirm betrachtet, sind die 80 Zeichen ein guter Richtwert.
    Ich hoffe, ich konnte ein wenig Input dazugeben. Danke auch für diesen Artikel, denn Tipps für guten Code kann man nicht oft genug geben!

  15. #15 Rex-Lii
    17. September 2015

    @Benni

    Was willst du mir damit genau sagen?

    Etwa, nur weil es irgendwo im Internet eine Seite gibt die Codeübersichtlichkeit erklärt bzw behandelt darf ich nicht darüber schreiben?
    Macht nicht viel Sinn.

  16. #16 Rex-Lii
    17. September 2015

    @Polygon

    Danke für den Kommentar.

    Ich bin halt noch am lernen, wie obens chon erwähnt habe ich demnächst zB Clean Code in der Schule.

    Ich wollte auch eher auf der Oberfläche bleiben. Einerseits weil ich selbst noch nicht allzuviel weiss und auch weil ich den Text auf für nicht-Programmierer oder die, die gerader erst anfangen lesbar und verständlich machen wollte.
    Steht in meinem 2. Satz des Artikels.

    Auch wenn ich mich n icht sehr gut auskenne, wollte ich trotzdem meinen Beitrag dazu leisten weil das auch der Sinn des Wettbewerbs hier ist. Ich darf auch mal ein Paar tipps zum Thema Codeübersichtlichkeit geben (bzw einen Artikel dazu schreiben) auch wenn ich noch nich alles beherrsche. Jeder darf mitreden. Auch die, die gerade erst anfangen und evtl. durch diesem Text merken dass sie das Ein oder Andere anders machen könnten.

    Nächstes Jahr kann ich ja ein etwas anspruchsvolleres Thema wählen, zB UML oder etwas in der Art.

  17. #17 Polygon
    17. September 2015

    @Rex-Lii:
    Ich wollte nicht zu harrsch sein. Ich habe schon gelesen, dass du noch am Anfang bist, daher habe ich noch ein paar Dinge erwähnen wollen. Außerdem schwingt da ein wenig Frust von meiner aktuellen Arbeit mit. Ich versuche ein Programm von jemand anderem zu optimieren, wo etliche Variablen nichtssagend sind und eine Routine auch mal 2000 Zeilen hat und entsprechend unübersichtlich ist. Dann noch alles in Fortran und schon fluche ich regelmäßig. 😀
    Was ich sagen will: Ich mag deinen Artikel und ich finde es super, dass du dich schon früh mit Struktur im Code beschäftigst.

  18. #18 Rex-Lii
    17. September 2015

    @Polygon

    Danke 🙂
    Ich freue michs chon Clean Code in der Schule zu haben, der Lehrer in diesem Fach (Modul 133) ist einfach spitze.

    Ich hoffe ich kann meine nächsten Programme (jetzt arbeite ich an einem Minesweeper) etwas übersichtlicher gestalten und besser kommentieren.

    Ich vergesse sehr gern das Kommentieren, versuche mich aber dran zu halten.

    Ich bin auch schrecklim im bennen von Dingen. Nicht nur Variabled und Methoden sondern auch das Finden von Titeln. Da weiss ich nie genau welcher Name bzw Titel denn gut passt. Ich kann mich generell sehr schlecht kurz fassen.

  19. #19 Rex-Lii
    17. September 2015

    @Polygon
    Ein weiterer Kommentar als Antwort zu dir wird gerade modieriert, müsste demnächst freigeschaltet werden.

    Anyway.

    Evtl zu meinen Kommentaren die quasi das offensichtliche wiedergeben.

    Mein Gedanke hinter diesen Kommentaren ist der, dass man kurz eine Info kriegt was innerhab dieser Methode gemacht wird.
    Bei meinen Zwei Popel-Methoden scheint das zwar irgendwie banal oder unnötig zu sein, aber bei grösseren Methoden kann ich mir persönlich vorstellen dass es Sinn macht. Ich habe 2-3 Methoden die locker mehr als den halben Code ausmachen (bei 371 Zeilen) und da scheint es mir sinvoll kurz beim Anfang der Methode kurz zu erklären was sie macht.

  20. #20 Ben
    17. September 2015

    Auch das “so wenig Code wie möglich” ist mit Vorsicht zu genießen. Ein Beispiel:

    int iVarA = 0;
    int iVarB = 0;
    …. //Hier passiert was mit den beiden Variablen
    label.Text = iVarA > iVarB ? “Ja” : “Nein”;

    Das ist kurz zu lesen und in manchen Fällen auch deutlich besser als das folgende Konstrukt:

    label.Text = “Nein”;
    if (iVarA > iVarB)
    {
    label.Text = “Ja”;
    }

    Das letzte finde ich jedoch besser lesbar, obwohl es mehr Zeilen hat (4 zu 1). Das ist also nicht allgemeingültig, dass weniger Code gleich alles übersichtlicher macht. 😉

  21. #21 Polygon
    17. September 2015

    @Ben:
    Geht es hier nur um die if-Abfrage? Ich finde die ersta Variante besser, wobei das schon eher eine Frage des Geschmacks ist. Grundsätzlich würde ich in der zweiten Variante ein else hinzufügen astelle label.Text erst auf “nein” zu setzen. Falls iVarA>iVarB wahr ist, dann würde man ja den Text zweimal setzen: Erst auf “Nein”, dann auf “Ja”. Aber beides ist besser als die geschweiften Klammern einfach wegzulassen, wenn nur eine Anweisung nach dem “if” kommt. Das führt schnell mal zu Bugs.

  22. #22 Rex-Lii
    17. September 2015

    @Ben

    Ich meinte meine Punkte auch eher als Richtlinien.
    Natürlich kann ein etwas längerer Code übersichtlicher sein, zum Beispiel ist mein Code auch etwas länger weil ich viele Abstände reinpacke. Das Selbe gilt bei vielen Texten die ich schreibe.

    Aber trotzdem kann es unübersichtlich werden wenn man quasi unnötig viel Code schreibt.

    Und am Ende hat auch jeder seinen eigenen Stil. 🙂

  23. #23 cimddwc
    17. September 2015

    Was das Sortieren von Variablen betrifft, möchte ich Moss the TeXie zustimmen – ich finde eine semantische/logische Gruppierung auch übersichtlicher. Und das nicht nur in Assembler, wo der Typ i.d.R. eh nicht so arg festgelegt ist. 🙂

    Ansonsten eine nicht ganz ernstgemeinte Anekdote: Real programmers don’t write commenrts 😉

  24. #24 Theres
    17. September 2015

    @Rex-Lii
    Ach ja … kommentieren 🙂 So hätte mir das früher mal wer erklären sollen … und das hier erwähnte, gute Buch gab es noch nicht, als ich mit Programmieren anfing. Gut erklärt und gute Beispiele hast du.
    Ich bin auch der für die semantische Gruppierung, übrigens. Liest und versteht sich später besser.

    @cimddwc
    😀

  25. #25 Volker
    Berlin
    17. September 2015

    ja, stimmt alles.
    Leider ist es in der Praxis oft so, dass die sich mit Überlichtgeschwindigkeit nähernde Deadline dafür sorgt, dass sämtliche guten An- und Vorsätze über Bord gehen und am Ende doch wieder nur eine traurige Aneinanderreihung von Code-Fragmenten übrigbleibt. Die zwar macht, was die Software soll, aber wehe der Person, die den Code dann irgendwann mal erweitern muss.
    Und das beste ist, wenn diese Person identisch mit derjenigen ist, die das Chaos ursprünglich mal verbrochen hat. Das passiert mir regelmässig.

    Schöner Artikel übrigens!

  26. #26 Rex-Lii
    17. September 2015

    @Volker
    Zur Zeit bin ich noch in der Ausbildung und da hab ich nicht soo viel Zeitdruck. Ich konnte mir extra etwas Zeit nehmen um noch mal den Code zu strukturieren und auszukommentieren 🙂

    @Theres
    Danke 🙂

    @Alle
    Danke für die Kommentare. Ich habe jeden gerne gelesen und so gut wie möglich versucht zu antworten.
    Auch dass der Artikel meist gut ankam freut mich auch sehr.
    Freue mich schon auf den nächsten Wettbewerb wo ich wieder mitmachen möchte 🙂

  27. #27 Dampier
    17. September 2015

    Hallo Rex-Lii, ein guter Artikel, vielen Dank!

    Strukturieren, Kommentieren und Dokumentieren sind letztlich bei jeder Art komplexerem Computerprojekt gefragt und man kann nicht oft genug darauf hinweisen. Wie oft musste ich alte Grafikjobs wiederaufnehmen, die miserabel bis gar nicht dokumentiert und völlig chaotisch abgelegt waren. Auf dem eigenen Rechner und erst recht auf dem Server Ordnung zu halten ist verdammt wichtig (aber wenn man das zu gewissenhaft betreibt, heißt es schnell “du arbeitest zu langsam”).

    Es gibt aber auch Firmen, die die Dokumentation etc. soweit treiben, dass man gar nicht mehr zügig arbeiten kann. Irgendwo kommt der Punkt, wo die “Bürokratie” mehr Zeit verbraucht als der eigentliche Job, ab da wird es kontraproduktiv.

    Für mich entscheidend ist die Nachvollziehbarkeit, (speziell wenn man einen nicht-trivialen Workflow erarbeitet hat) d. h. ich denke immer an die unbekannten Grafiker/innen, die irgendwann nach mir diesen Job wieder aufnehmen müssen. Ich versuche, es ihm/ihr möglichst leicht zu machen.

    Keine Ahnung, ob das jemals jemand zu würdigen gewusst hat … 😉

    grz
    Dampier

  28. #28 dgbrt
    18. September 2015

    @Rex-Lii:
    Nette Einführung und ich wünsche dir viel Erfolg bei deiner weiteren Ausbildung.

    Es gibt zu diesem Thema so viele Abhandlungen, dass das wohl niemand mehr alles lesen kann. Aber ich kenne sehr viele Programmierer , die wenigstens mal ein Buch davon lesen sollten. 😉

    Generell denke ich, das der Code so aufgebaut wird, dass Kommentare oftmals gar nicht notwendig sind.

    Also:

    private void paintTextInPictureBox(String text, PictureBox pBox)
    {
    ...
    }

    Damit ist eigentlich in diesem Fall kein Kommentar mehr notwendig.

    Wenn schon kommentiert wird, dann in Englisch und vor allem die Parameter erklären. Sonst muss man ja den Code der Methode lesen, um zu verstehen was ich beim Aufruf übergeben muss. Das sieht in diesem Fall natürlich albern aus, bei komplexeren Methoden ist das aber dringend angeraten. Der Name der Methode bleibt auch etwas kürzer.

    /*
    * method paintPictureBox - render the text into the picture box
    * text(String): the text to be rendered
    * pBox(PictureBox): the picture box
    */
    private void paintPictureBox(String text, PictureBox pBox)
    {
    ...
    }

    Es gibt hierzu auch Standards wie z.B. JavaDoc. Meine Kenntnisse in VisualStudio sind leider begrenzt, da wird es so etwas aber auch geben. Wenn ich die Methode jetzt aufrufen will, zeigt einem die IDE (also der Editor) genau diese Hilfe an.

    Und der Code selbst sollte durch sinnvolle Leerzeilen ähnlich strukturiert werden wie man das bei einem normalen Fließtext mit Hilfe von Absätzen auch macht.

    Und noch so eine Marotte, die ich gar nicht mag: Code, der nicht mehr benötigt wird, sollte man löschen und nicht einfach nur auskommentieren. Das erhöht die Lesbarkeit ungemein.
    Wenn man das dann nach einem halben doch noch mal braucht (meistens trifft das nicht zu) hat man das auch schnell wieder neu geschrieben.

  29. #29 Moss the TeXie
    Ladenburg
    18. September 2015

    Code, der nicht mehr benötigt wird, sollte man löschen und nicht einfach nur auskommentieren. Das erhöht die Lesbarkeit ungemein.

    Stimmt.

    Wenn man das dann nach einem halben

    Augenblick? Tag? Jahr? Leben? Herzkasper? Schweinsbraten?

    doch noch mal braucht (meistens trifft das nicht zu) hat man das auch schnell wieder neu geschrieben.

    Wenn man ein CVS wie z. B. Subversion, Mercurial oder Git benutzt und regelmäßig committet, kann man Änderungen und Löschungen recht einfach zurücknehmen, auch zeilenselektiv. Ich benutze auch gern einen Entwicklungszweig (Git), wo ich Änderungen bequem entwickeln und entwanzen kann, um sie am Ende in den Releasezweig zu mergen.

  30. #30 Rex-Lii
    18. September 2015

    @dgbrt

    Das mit dem nicht benötigten Code löschen, im nachhinein ist mir das auch aufgefallen.
    Also das Programm war auch noch nicht ganz fertig. Also es war fertig aber quasi in einer alpha oder beta version.

    Am Ende hab ich dann alle unnötigen Kommentare gelöscht.
    In meinem aktuellen Projekt kann ich ja in dem von dir erwähnten stil kommentieren. 🙂

  31. #31 Crazee
    18. September 2015

    Danke für den Artikel. Ich gehöre zur Gattung “Erstellt graphisch-interaktiv gestalteten Code mit LabVIEW, der grundsätzlich weder kommentiert noch dokumentiert ist”

    Nächstes Jehr gerne etwas in Deinem Stil über Zustandsautomaten 😉

  32. #32 Rex-Lii
    18. September 2015

    @Crazee
    Ich schaue mal was ich nächstes Jahr schreibe.

    Ich wollte evtl auch mal etwas über Physik in Computerspielen machen bzw über gewisse Mechaniken in Spielen wie Portal (2).
    Ich weiss jetzt nicht ob du das Spiel kennst aber es hat lustige und interessante Physik mit der man die Levels lösen muss.

    Der Hintergedanke daran ist: Computerspiele können auch inteligent sein, spass machen und auf jeden Fall mal einen Versuch wert 🙂

  33. #33 sax
    18. September 2015

    Ich setze bei der Erstellung einer Dokumentation Doxygen, dann kann man die Dokumention gleich beim Programmieren erstellen.

  34. #34 Ramoncito
    18. September 2015

    @ Mibit :

    Du hast das Buch “Clean Code” von Robert C. Martin erwähnt.

    Ist das auch interessant für Nicht-Programmierer?
    Bringt das Buch einem Software Tester etwas, der nicht unbedingt codieren muss?

  35. #35 klauswerner
    Pommelsbrunn
    18. September 2015

    Ein netter Einsteigerartikel.
    Noch ein Tipp, der schneidig bewährt hat: oft kapsele ich Standard-Funktionen. Damit meine ich, ein OpenFile wird zu einem Int_OpenFile in einer eigenen Funktion. So kann ich um das Kommando noch eigene Funktionen darum herum legen, wie zum Beispiel ein Array, das sich alle offenen Dateien merkt.
    Am Ende des Programmes habe ich dann ein Int_Exit, mit dem ich das Array prüfen kann und feststellen kann ob noch Dateien zu schließen sind – und diese dann auch schließen.

    Das ist in dem Fall jetzt nur ein Beispiel, man kann sich da ganz viel ausdenken. Mit Datenbank-Verbindungen, Eingabefeldern und vielem mehr. So gab es in meinen Programmen eine Funktion um eine Fusszeile mit Hilfstexten ein oder auszuschalten. Und da ich eine eigene Funktion für Eingabefelder hatte, eben ergänzt um einen Hilfetext, war der im System eben vorhanden und wurde je nach User-Einstellung in einer Fusszeile angezeigt oder nicht.
    Ein Sort alphanumerischer Felder hat so generell das Problem der Umlaute behoben, es war eben ein Int_Sort.

    Mit der Zeit hatte ich so eine schöne Sammlung schicker Int_ Befehle, die viele kleine Zusatzdinge nebenher erledigt haben, über die ich nie wieder nachdenken musste.

    Ich hoffe ich habe das so verständlich rüber gebracht.

  36. #36 Ulf Lorenz
    18. September 2015

    Ein paar Dinge, die mir bei deinen Codebeispielen noch auffallen:

    Erstmal ist die Variablendeklaration unuebersichtlich. Ausser in Spezialfaellen sollte eine seitenlange Variablenliste nie auftauchen. In deinem Fall sind z.B. endlos viele, relativ trivial strukturierte, Strings fuer die einzelnen Laender. Das liesse sich einfach in eine Funktion auslagern, z.B. “getResourcePath(string country)”. Die Liste der Laender schreit nach einem Aufzaehlungstyp.

    Wohlgemerkt, diese Aenderungen machen deinen Code evtl. sogar laenger, aber man muss sich nicht durch die ganzen Details wuehlen, um zu verstehen, was dein Code macht.

    Naechster Punkt: Lokalisierung. Du hast drei Booleans flip, flap, flop definiert. Muessen die wirklich in der Klasse definiert sein, oder kann man sie in der Funktion erzeugen, wenn sie gebraucht werden? Dasselbe gilt fuer den Block right_move etc. darunter. Damit willst du vermutlich durch deine Reihen durchgehen, dann kannst du die Variable auch gleich dort definieren.

    Das hilft dann auch automatisch beim letzten Punkt, der Benennung der Variablen. Die ist nicht immer gelungen, z.B. wrong_move, bla. Teilweise bringt Lokalisierung etwas, dann ist z.B. klar, dass “bla” nur eine sinnlose Variable ist, die aber verlangt wird. Teilweise koenntest du noch etwas mehr Arbeit in genau dem richtigen Variablennamen investieren.

    Das Saeubern von Code laesst sich nebenbei auch oekonomisch begruenden. Angenommen, 10 Leute lesen durch deinen Code, und jeder von denen benoetigt dank Saeubern 5 Minuten weniger zum Verstehn, dann kannst du 45 Minuten darin investieren und hast immer noch Arbeitszeit gespart. Das wird richtig schlimm bei Wissenschaftscodes, wo das Verstehen schnell mal eine Woche extra bei dutzenden Nutzern wird (und die trotzdem meist grausamst sind).

  37. #37 Rex-Lii
    18. September 2015

    @Ulf Lorenz

    Der Code an sich ist hier nicht wichtig.
    In einer neueren Version des Programms beziehe ich die Files direkt über die resources.resx.

    Die 3 booleans wurden oben deklariert weil ich sie quasi mehre male brauche. Beim 1. Klick ist zb flip von true auf false. Beim 2. Von false auf true und so hin her.

    Das finale Programm hat 371 Zeilen btw.

  38. #38 Moon
    19. September 2015

    Tipp: jpg ist für Fotos. Screenshots von GUIs macht man in png, die sind dann kleiner und haben keine Artefakte.

  39. #39 BreitSide
    Beim Deich
    8. Oktober 2015

    Später Kommentar… ;-(

    Ich kenne das Problem schlechter Kommunikation von einem größeren Ing-Büro: Da hatte jemand es genial geschafft, den Sekretärinnen 3 Zeilen mehr im Bildschirm für Word zu gönnen.

    Dann schied er aus, und kein Schw*** kannte sich mehr aus 🙄

    Genau genommen ist für fast jede nicht triviale Arbeit eine saubere Dokumentation wichtig. Auch wenn das jedes Mal wie eine Syphilisarbeit anmutet.