Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

Grundlagen der Programmierung: Codemetriken

Was ist schlechter Code?

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Schlechter Code fällt jedem Entwickler schnell auf. Dabei ist so eine Qualitätseinstufung sehr subjektiv. Woran liegt das?
05:50

Transkript

Bevor wir uns damit beschäftigen können, was Code-Metriken sind, müssen wir uns damit beschäftigen, was schlechten Code ausmacht und warum wir Code als schlecht empfinden. Können Sie mir sagen, was da steht? Ist gar nicht so einfach oder? Machen wir es einfacher. Genau, das steht, gemäß einer Studie einer englischen Universität ist es nicht wichtig, in welcher Reihenfolge die Buchstaben eines Wortes vorkommen, insofern der erste und letzte Buchstabe übereinstimmt. Wie wir am ersten Beispiel sehen, ist das nicht ganz korrekt, diese Aussage, und es ist eigentlich auch das, womit sich die Webseite aus der Quelle beschäftigt. Denn es reicht nicht aus, dass der Anfangs- und Endbuchstabe stimmt, sondern das Muster der Methode muss generell eingehalten werden. Wir haben in der Schule gelernt, dass wir nicht jeden Buchstaben einzeln lesen müssen, sondern wir haben gelernt, welche Buchstaben zu einem Wort gehören. Wenn die ein bisschen durcheinandergeraten, dann ist das vielleicht kurz schwierig zu lesen, aber es ist dennoch für uns verständlich. Wenn wir nun Quellcode lesen, dann ist es das Gleiche. Wir müssen nicht erkennen, was tatsächlich in einer Methode passiert, und tatsächlich, wenn wir einfach nur auf Quellcode schauen, dann erkennen wir meistens auch nicht sofort, was die Methode macht, sondern wir haben eine Grundvorstellung, wie diese Methode aufgebaut sein müsste. Wir wissen, da gibt es eine Sichtbarkeit, wie "Private", "Public", usw. und so fort, es gibt einen Namen und es gibt eine Parameterliste, all das ist die Methodensignatur, und danach kommt der eigentliche Methoden-Body. Sie werden jetzt eventuell mit dem Kopf schütteln, denn für Sie sehen solche Methoden vielleicht nicht genau so aus wie hier. Wenn Sie z. B. in JavaScript schreiben, dann haben Sie keinen Qualifizierer vor der Methode, Sie haben keinen Rückgabewert, der angegeben wird, oder die geschweifte Klammer, die kommt dann meistens direkt nach der Methodensignatur. Und damit fühlt sich für Sie C# etwas eigenartig an, für mich als C#-Entwickler wiederum ist es eigenartig, wenn die geschweifte Klammer nicht auf einer Eins in einer Zeile kommt. Und damit gehen sie dann schon los, die Glaubenskriege, und es geht noch weiter. Wenn wir z. B. Objective-C sehen, ein Beispiel für eine Sprache, die nicht so viel anders ist als vieles, was wir aus Sprachen wie C++ und Co. kennen, aber was für viele Entwickler auf den ersten Blick sehr ungewöhnlich erscheinen kann. Für die meisten Entwickler ist es so, wenn sie darauf schauen, dann sind sie erst einmal damit beschäftigt, sich darin zurecht zu finden. Was sind das alles für Schlüsselwörter und so weiter und so fort. Man fühlt sich zurückversetzt in die Zeit, als man angefangen hat, zu programmieren, als man das Programmieren gerade gelernt hat. Man kann sich also nicht auf seine Arbeit konzentrieren, sondern ist damit beschäftigt, auseinander zu nehmen, was dort eigentlich steht. Und genau das macht für uns häufig schlechten Code aus. Nehmen wir dieses Beispiel, es ist C#. Und kein Entwickler, bis auf den, der es geschrieben hat, wird das als Standard erkennen. Es fühlt sich äußerst unangenehm an, dies zu lesen, und das ist nicht nur so, weil die Methodensignatur falsch dargestellt wird, sondern weil beispielsweise Variablen mit "v_" eingeleitet werden. Dies sind Kleinigkeiten, aber sie machen das Lesen schwer. So würde ich beispielsweise die Methode schreiben, in normaler, verständlicher Art und Weise für C#-Entwickler. Das Interessante ist jetzt, dass ich mich sehr lang damit beschäftigt habe, wie Quellcode aussieht, aber tatsächlich ist das nicht alles, was schlechten Quellcode ausmacht, es ist nur das, was uns zuerst ins Auge fällt und wo wir am meisten versucht sind, dran zu ändern. Häufig ist es so, dass wir das, was wir sehen, nicht verstehen und damit wir es verstehen können, wollen wir es anpassen. Wir wollen es in unsere Mustererkennung einfügen, wir wollen unsere Muster auf den Code, den wir sehen, übertragen. Und das ist falsch. Dies ist nicht objektiv, es kostet viel Zeit und es verursacht häufig nur noch mehr Probleme. Denn das, was wir noch nicht adressiert haben, ist das Design hinter dem Quellcode. Das, was im C# geschrieben ist, quasi die sprachlichere Repräsentanz des Verhaltens unserer Software. Das ist nicht alles. Das Design selbst muss bestimmten Regeln entsprechen, und dieses Design wird eben mit entsprechenden Metriken objektiv geprüft. Ist der Code zu starr, wodurch Änderungen an einer Stelle ganz andere Stellen beeinflussen. Ist er zerbrechlich, dass Dinge kaputt gehen, wenn man Änderungen vornimmt oder kann er überhaupt nicht wiederverwendet werden, weil er unbeweglich ist, weil er zu hart eingebacken ist in die Gesamtstruktur. Also schlechten Code macht nur aus, dass wir ihn nicht gut lesen können, schlechten Code macht grundsätzlich aus, dass er komplexer ist, als notwendig. Er hat ein zu großes Volumen beispielsweise. Er ist schlecht geschrieben, im Sinne von, er ist nicht leserlich geschrieben. Denn wenn wir ihn nicht lesen können, können wir ihn nicht verstehen, wenn wir ihn nicht verstehen können, können wir ihn nicht verändern. Interessanterweise hält uns das im Alltag nicht davon ab, es trotzdem zu verändern, was meistens dazu führt, dass wir noch weitere Probleme haben, weil wir nicht verstanden haben, was wir ändern. Wir müssen also dazu übergehen, wenn wir guten Code schaffen wollen, dass er wenig komplex ist, dass er einfach verständlich ist und damit, leicht zu verändern.

Grundlagen der Programmierung: Codemetriken

Lernen Sie Methoden, Prinzipien und Werkzeuge kennen, mit deren Hilfe Sie die Qualität Ihrer Software dauerhaft sicherstellen können.

1 Std. 43 min (20 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Exklusiv für Abo-Kunden
Erscheinungsdatum:25.04.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!