Kommen wir zum nächsten Punkt: Je weniger Code desto besser.
Das macht ja Sinn. Verglichen mit anderen Arbeitsplätzen ist es ja auch aufgeräumter und übersichtlicher wenn weniger Dinge auf dem Schreibtisch liegen.
Den Code kann man auf verschiedene Arten kürzen. Eine Variante ist das Verwenden von Schleifen:

loop

Was der Code macht ist nicht weiter wichtig. Ihr müsst nur Wissen dass ich mithilfe einer Schleife durch eine Liste von Pictureboxen(Dort werden Bilder eingefügt) gehe und so jede Picturebox bearbeite. Insgesamt sind es 16 Pictureboxen. Ohne die Schleife müsste ich den Code 16 mal Copy-Pasten. Möchte ich eine kleine Änderung an diesem Code vornehmen müsste ich dies dann 16 mal tun. Durch die Schleife muss ich aber nur einmalig was ändern.

Ein zweiter Weg um Code zu sparen ist das Auslagern von häufig verwendetem Code in sogenannte Methoden. Dazu wieder ein Bild:

methoden

Dieses Bild ist in 3 Teile unterteilt. In der Mitte haben wir die Methode Paint. Oben und unten können wir sehen wie diese Methode aufgerufen wird. Der Inhalt der Methode ist 6 Zeilen lang (Ohne die Kommentare und abstände) und sie wird Zwei mal aufgerufen. Würde ich direkt den Inhalt der Methode an beiden Stellen verwenden wären das 2*6 Zeilen = 12 Zeilen Code.
Da ich den Code aber in einer Methode ausgelagert habe und der Aufruf dieser Methode je nur eine Zeile benötigt, ergibt das Total: 6 Zeilen + 2*1 Zeile pro Aufruf = 8 Zeilen. Also benötigen wir in diesem Bespiel 33% weniger Code. Da ich viel Code in verschiedensten Methoden ausgelagert habe ist die Gesamtersparnis schon recht ordentlich.
Und hier auch wieder: Wenn wir den Code der Paintmethode ändern wollen müssen wir ihn nur einmal ändern und nicht Zwei oder Drei mal, jenachdem wie oft wir die Paintmethode verwenden.

Auf dem Bild zum Thema Methoden konnten wir noch etwas anderes erkennen: Kommentare (Grüne Schrift).
Kommentare helfen ungemein bei der Leserlichkeit und Verständlichkeit des Codes. Einerseits kann man so kurz erklären was zB eine Methode oder ein Code Teil macht, aber man kann auch so den Beginn einer Methode kennzeichnen damit man leichter Sieht was wo anfängt und aufhört.

Kommentare

In diesem Bild kann man sehr gut erkennen wie Kommentare die Verständlichkeit und Leserlichkeit des Codes erhöhen.
Wir sehen die 2 Methoden Paint und frm_Paint.
Jetzt bist du, werter Leser, gefragt: Sage mir wie sich diese 2 Methoden unterscheiden? Dank der Kommentare kann selbst Jemand der nicht programmiert diese Frage recht einfach beantworten.

Wenn wir beim Thema Kommentare sind kann ich auch erwähnen dass eine Dokumentation des Projekts auch sehr wichtig ist. Kommentare sind eine Art der Dokumentation innerhalb des Codes. In vielen Fachbereichen ist es Sinnvoll seine Arbeit zu Dokumentieren und zu erklären. Egal ob man, wie ich, ein Memory programmiert, ein neues Auto entwickelt oder ein wissenschaftliches Experiment aufstellt und durchführt. Dokumentieren ist eines der wichtigsten Aufgaben eines Programmierers. Genauso wichtig, evtl. noch wichtiger, wie das Programmieren selbst. Die Dokumentation wird benötigt wenn man zum Beispiel nicht mehr am Programm arbeitet und ein neuer Programmierer sich einarbeiten muss. Eine gut erstelle Dokumentation ist in solchen fällen Gold wert. Und auch die oben erwähnten 3 Punkte warum man übersichtlichen Code benötigt beantworten die Frage wieso man eine gute Dokumentation braucht.

Okay, das war es erstmal von mir. Es gibt noch viel mehr zu erzählen über übersichtlichen Code und wie man zB besser kommentiert und so weiter.

Als Fazit kann man sagen, dass man recht schnell mithilfe der hier erwähnten Tipps den Code schon recht übersichtlich hinbekommt. Die Tipps lassen sich auch auf das Erstellen von normalen Texten übertragen.

Ende 🙂
————————————————-
Hinweis zum Autor: „Mein Name ist Rex-Lii und ich bin Programmierer in Ausbildung. Ich schreibe einen Fan Fiction in Englisch auf Deviant Art: https://spacegandhi.deviantart.com/“

1 / 2

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.