Das sagt Wikipedia zum Thema:
„Bei Code-Smell geht es nicht um Programmfehler, sondern um funktionierenden Programmcode, der aber schlecht strukturiert ist. Das größte Problem liegt darin, dass der Code für den Programmierer schwer verständlich ist, so dass sich bei Korrekturen und Erweiterungen häufig wieder neue Fehler einschleichen. Code-Smell kann auch auf ein tieferes Problem hinweisen, das in der schlechten Struktur verborgen liegt und erst durch eine Überarbeitung erkannt wird.“
(https://de.wikipedia.org/wiki/Code-Smell, abgerufen am 30.4.2020).
Code-Smells – was heißt das konkret?
Ob Software für PC-Anwendungen oder Applikationssoftware für Maschinen und Anlagen – „stinkende“ Problemstellen kann es in allen Bereichen geben. Was ist gemeint?
Problematisch können unter anderem Codestellen sein, in denen
- mehrfach auf Ausgänge geschrieben wird,
- Code im Projekt zwar angelegt ist, aber nicht aufgerufen wird bzw. nicht erreichbar ist,
- Programmbausteine angelegt wurden, die aber keinen Code beinhalten,
- zu wenig Kommentare hinterlegt wurden, was eine spätere Überarbeitung erschwert,
- identisch deklarierte Variablen in unterschiedlichen Objekten auftreten und somit verwechselt werden können,
- implizite Konvertierungen vorgenommen werden, die das System ggf. anders ausführt als vom Applikationsprogrammierer vorgesehen,
- Anweisungen auskommentiert und nicht gelöscht wurden, so dass die Kommentare vermuten lassen, dass solche Stellen einfach vergessen wurden,
- eine bestimmte Variable geschrieben, aber nie wieder gelesen wird,
- Divisionen mit Variablen durchgeführt werden, die unter Umständen zu einer Division durch „0“ führen können.
Für Automatisierer ist das Risiko sogar noch größer: Während Software-Entwickler für Desktop- oder mobile Apps im schlimmsten Fall einen Systemabsturz und die Verärgerung der Anwender riskieren, kann es für Automatisierer um sehr viel Geld gehen. Zum Beispiel dann, wenn sich die Inbetriebnahme von Maschinen und Anlagen deutlich verzögert, einfach deshalb, weil die „Stinkestellen“ Ärger machen. Akute Fragen wie „Warum wird denn dieser Code nicht ausgeführt?“ oder „Warum ändert sich der Wert dieser Variable jetzt plötzlich?“ müssen dann durch aufwendiges Debugging beantwortet werden. Noch teurer kann es werden, wenn Problemstellen erst nach längerer Laufzeit einen Ausfall von Maschinen oder Anlagen verursachen.
Manuell ist eine systematische Suche nach Problemstellen gerade in komplexeren Projekten nahezu unmöglich. Um diese zu finden, verwenden Informatiker für Desktop- oder App-Software meist Zusatztools zur statischen Code-Analyse. Durch formale Prüfung des Quelltextes können Fehler so frühzeitig entdeckt werden. Leider lassen sich die vielen verfügbaren Tools wie Lint, FxCop oder CodeIt.Right nur für Programmcode in Hochsprachen anwenden – und damit nicht für Automatisierer (siehe auch Wikipedia, „List of tools for static code analysis“).
Für die Anwender des marktführenden und herstellerunabhängigen Entwicklungssystems CODESYS ist jedoch ein Zusatztool verfügbar, das genau dieses Auffinden von problematischen Codestellen automatisiert durchführt: CODESYS Static Analysis.
Abb.1 Screenshot: Auswahl von Regeln für die statische Code-Analyse
Prüfung anhand von Regeln
CODESYS-Anwender können mit diesem vollständig integrierten Zusatztool zunächst festlegen, anhand welcher Regeln der Quellcode überprüft werden soll. Zur Verfügung stehen weit mehr als 100 Regeln, die sich u. a. aus den bereits genannten Problemstellen ergeben. Zusätzlich stehen zahlreiche weitere Regeln zur Verfügung. So lässt sich beispielsweise prüfen, ob Erweiterungen über die Definitionen der IEC 61131-3 hinaus zum Einsatz gekommen sind. Der Anwender legt selbst fest, nach welchen Regeln seine Applikation untersucht werden soll, und ob Fundstellen lediglich eine Warn- oder sogar eine Fehlermeldung erzeugen. Dies ist vor allem dann sinnvoll, wenn z. B. ein Projekt bereits für Maschinenerweiterungen vorbereitet ist und daher Code enthält, der nur in einer anderen Maschinenvariante zum Einsatz kommt. In einem solchen Fall lässt sich die entsprechende Regel einfach abschalten. Andere Regeln wie die Prüfung auf eine maximale Variablengröße kann der Anwender sogar parametrieren. Zum schnellen Auffinden und Einordnen können Regeln nach unterschiedlichen Kriterien sortiert werden, z. B. nach Wichtigkeit. Der Anwender kann sämtliche Einstellungen in eigenen Regelsätzen ablegen und wieder aufrufen, um bei Bedarf Überprüfungen von unterschiedlichen Maschinentypen nach spezifischen Regelsätzen vornehmen zu können.
Implizite oder explizite Ausführung
Viele der Regeln kann das CODESYS Development System bereits während der Codierung und damit vor dem eigentlichen Übersetzungsvorgang überprüfen, vorausgesetzt, die entsprechende Option ist aktiviert. Somit erhält der Anwender bereits beim Programmieren wertvolle Hinweise zur Verbesserung der Codequalität. Die Überprüfung kann aber auch explizit angestoßen werden. In jedem Fall zeigt das CODESYS Development System die Fundstellen im Meldungsfenster bzw. direkt im Quellcode an. Einfach zu behebende Punkte Fundstellen können per Quickfix unmittelbar korrigiert werden, und zwar entweder im Meldungsfenster mit Hilfe eines neuen Buttons, oder per rechter Maustaste im Quellcode. Nicht erreichbaren Code kann der Anwender sofort löschen.
Abb.2 Screenshot: Viele Fundstellen der statischen Code-Analyse lassen sich per Quickfix beheben.
Was aber, wenn gefundene “Stinkestellen“aufgrund einer bestimmten Regel an manchen Stellen sinnvoll sind, an anderen jedoch nicht? In diesen Fällen helfen spezielle Pragma-Anweisungen. Damit kann der Anwender den betreffenden Quellcode ähnlich wie HTML-Tags umschließen und eine oder mehrere einzelne Regelprüfungen für diese Stellen ausklammern. Ein solches Vorgehen ist besonders dann sinnvoll, wenn es sich um gewollte Abweichungen handelt, die aber nur an bestimmten Stellen zulässig sind. Diese Pragmas sind nur für die statische Code-Analyse relevant, in der sie gesetzt wurden. Sie haben keine Auswirkungen auf den finalen Applikationscode.
Auch Namenskonventionen und Codierrichtlinien lassen sich explizit durch CODESYS Static Analysis überprüfen. Der Anwender definiert dazu Präfixe, mit denen Variablen, Programmbausteine oder benutzerdefinierte Datentypen eines bestimmten Typs gekennzeichnet sein müssen. Darüber hinaus kann er verbotene Symbolnamen angeben, auf die dann ebenfalls geprüft wird. Im Rahmen des Prüflaufs werden solche Abweichungen dann ebenfalls im Meldungsfenster angezeigt.
Statistische Kennzahlen zur Codequalität
CODESYS Static Analysis bietet Applikationsentwicklern Kennzahlen, die ein Maß für die Qualität des erstellten Codes darstellen. Zur Verfügung stehen klassische Erhebungsmethoden wie die McCabe-Metrik zur Bestimmung der Komplexität von Softwaremodulen. Daneben können viele weitere Kennzahlen automatisch ermittelt werden, z. B. für die Verschachtelungstiefe, die Anzahl von Anweisungen in den Bausteinen oder die Prozentzahl von Anweisungen mit hinterlegten Kommentaren. Alle diese Metriken dienen dazu, die Lesbarkeit und Wartbarkeit des Codes zu erhöhen. Es kann für den Anwender sinnvoll sein, solche Werte in einem bestimmten Bereich zu halten. In CODESYS Static Analysis kann er dafür Grenzwerte angeben und sich mit Hilfe eines sogenannten Kiviat-Diagramms die Einhaltung interessanter Grenzwerte sogar grafisch anzeigen lassen.
Code besser strukturieren
Wer kennt das nicht? Beim Programmieren einer Applikation beginnt man mit einem Baustein, in den man viele Anweisungen hineinpackt. Werden bestimmte Anweisungssequenzen häufiger benötigt, kopiert man diese einfach und ändert lediglich die erforderlichen Variablen oder Konstanten - statt die Sequenzen in eigene Bausteine auszulagern. Irgendwo im Hinterkopf denkt man sich: „Wenn ich später Zeit habe, ziehe ich das gerade, so dass der Code dann schöner lesbar und besser strukturiert ist.“ Leider bleibt dafür dann doch meist keine Zeit übrig! Und so muss sich der Kollege, der später vor Ort die Inbetriebnahme durchführt und Änderungen am Applikationscode benötigt, durch einen Wust an Anweisungen durchkämpfen.
Abb. 4 Screenshot: Toolgeführtes Erkennen von kopiertem Code
Auch für diesen Fall bietet CODESYS Static Analysis Abhilfe: Im Strukturierten Text können markierte Anweisungen per Mausklick automatisiert in eine Funktion oder Methode ausgelagert werden. Insbesondere dann, wenn es sich um kopierten Code handelt, wird diese Eigenschaft besonders wertvoll: Zunächst identifiziert die sogenannte Clone Detection kopierten Code, der sich vom Original höchstens um verwendete Variablennamen und konstante Werte unterscheidet. Für solchen Code ist eine Auslagerung in gemeinsam verwendete Funktionen oder Methoden besonders sinnvoll. Die gesamte Applikation wird dadurch besser lesbar und überschaubar. Gegenüber einer manuellen ist die toolgeführte Optimierung wesentlich schneller und liefert gleichzeitig zuverlässigere Resultate, da klassische „Flüchtigkeitsfehler“ einfach nicht vorkommen.
Abb.5 Screenshot: CODESYS Static Analysis unterstützt beim Auslagern von kopiertem Applikationscode.
Fazit
Mit einem integrierten Zusatztool zur statischen Code-Analyse können Applikationsentwickler die Qualität ihrer Applikationssoftware steigern und typische Probleme von vornherein vermeiden, kurz und gut: Sie können sich damit Zeit, Geld und Ärger sparen. Sicherlich ist dazu nicht unbedingt ein Zusatztool nötig. Die Praxis zeigt jedoch, dass manuelle Prüfung und Optimierung des Quellcodes in der Regel im täglichen Arbeitsalltag untergehen. Und so sind in vielen Maschinen und Anlagen weiterhin „stinkende“ Codestellen vorhanden – mit den entsprechenden Konsequenzen.
Statische Code-Analyse bietet wertvolle Unterstützung dabei, Problemstellen in kürzester Zeit zu finden und zu beheben. Damit wird sauber geschriebener Applikationscode auch unter Zeitdruck möglich. Eine „dufte“ Sache, oder?
Video zum Artikel: https://youtu.be/Q7lf5ceYBc8
Artikel als PDF zum Download (400 KB): Stinker finden und beseitigen – Mit statischer Code-Analyse zu besserem SPS-Applikationscode
Autor Roland Wagner, Head of Product Marketing, CODESYS Group
erschienen in der Open Automation, Ausgabe 03/2020
Bildnachweis:
Screenshots, CODESYS Group
Hund: iStockphoto.com | brunorbs