Kann statische Code-Analyse den Code grüner machen?

Einleitung

Die statische Code Analyse ist ein einfaches Werkzeug und existiert auch, mehr oder weniger, seitdem Software existiert [1]. Dementsprechend einfach funktioniert statische Code Analyse auch: Codeabschnitte/-zeilen werden mit einem Muster verglichen, “schlechter” Code wird markiert und eine verbesserte Version vorgeschlagen.

Aufgrund der statischen Natur dieser Analyse lassen sich einige Kritikpunkte formulieren. Der Code wird hier aus dem Kontext gerissen, eventuell lässt sich dieser “schlechte” Code nicht anders Implementieren. Ein weiterer möglicher Kritikpunkt ist, dass nur ein kleiner Teil der Umweltbelastung in der IT durch den Code selbst verursacht wird. Zwischen einzelnen Codezeilen und dem Ressourcenverbrauch dieser liegen viele Ebenen (Compiler, Infrastruktur/Architektur, Hardware, Strommix, etc.) die einen Einfluss auf die Umweltbelastung haben. Die Legitimität dieser Kritikpunkte soll im Folgenden des Blogartikels untersucht werden.

Die größten Energieverbraucher der IT sind Bereiche, in denen der Code selbst keinen großen Einfluss auf den Energieverbrauch hat: Netzwerk/-Infrastruktur, IoT und Datenzentren [3]. Trotzdem darf man die statische Code Analyse nicht komplett aus den Augen verlieren, auf Code-Ebene gibt es eben keine bessere Möglichkeit die Umweltbelastung zu reduzieren, als den Code effizienter zu gestalten. Mal abgesehen davon sollte beim Thema Umweltbelastung auch jede Möglichkeit ausgenutzt werden, schließlich schalten wir unsere Lampen bei Nacht auch aus, obwohl die Umweltbelastung durch eine einzelne Lampe sicherlich vernachlässigbar ist.

Statische Code Analyse

Statische Code Analyse ist ein Verfahren, bei dem Code(-abschnitte) nach bestimmten ”schlechten” Schemen durchsucht und dann mit vorgefertigtem Code verglichen werden. Sollte der selbst geschriebene Code mit einem der “schlechten” Schemen übereinstimmen, wird dieser markiert und die meisten Tools bieten dann eine “bessere” Alternative an. Diese Alternative sollte in der Funktionalität das gleiche bieten oder zumindest sehr ähnlich sein. Die “schlechten” Schemen werden meistens in sogenannten Regeln festgehalten. Beispielsweise können wir folgende Regel definieren: “Schlechter” Code var++, Verbesserungsvorschlag ++var, bei jeder Variable, die nach dem “schlechten” Schema deklariert ist, wird nun der Codeabschnitt markiert und als fehlerhaft angezeigt. Auch wenn die Grundlegende Funktionalität bei beiden Versionen gleich ist: var = var + 1, erfolgt das + 1 einmal vor und einmal nach Ausführung der Zeile.

Die Idee der Verbesserung ist, dass im Fall +1 nach Ausführen der Zeile (var++) der Wert in einer temporären Variable gespeichert werden muss, anstatt wie bei ++var der Wert direkt zugewiesen wird. Dabei verbraucht die temporäre Variable zusätzliche Ressourcen.

Offensichtlich kann die Version ++var allerdings nicht immer angewendet werden. Statische Code Analyse Tools sollten daher auch niemals selbstständig und automatisiert Verbesserungen anwenden, allenfalls einzelne, unverfängliche Regeln ( Bsp.: leere Zeile am Ende einer Datei, etc.). Das bedeutet aber auch, dass zusätzliche Zeit investiert werden muss, um die einzelnen Regeln zu überprüfen und gegebenenfalls zu verbessern. Das Verhältnis zwischen Aufwand und nutzten muss dementsprechend passen, sonst lohnt sich das Verfahren nicht. Allgemein werden mit der statischen Code Analyse verschiedene Ziele verfolgt:

• Fehlererkennung: Identifizieren potenzieller Codierungsfehler und Bugs, bevor das Programm ausgeführt wird, was dazu beitragen kann, Probleme in der Produktion zu verhindern
• Verbesserung der Codequalität: Sicherstellen, dass der Code Best Practices und Codierungsstandards entspricht, wodurch er wartbarer und lesbarer wird
• Sicherheit: Identifizieren von Sicherheitslücken und potenziellen Schwachstellen im Code, die von Angreifern ausgenutzt werden könnten
• Leistungsoptimierung: Erkennen von Codemustern, die zu Leistungsproblemen führen können, wie z. B. Speicherverluste oder ineffiziente Algorithmen
• Konsistenz: Durchsetzung von Codierungsstilen und -konventionen in einer Codebasis, wodurch die Zusammenarbeit mehrerer Entwickler an einem Projekt erleichtert wird.

Statische Code Analyse - Green IT

Prinzipiell hat die statische Code Analyse keinen direkten Bezug zu Green IT, allerdings bietet es sich an, weitere Regeln einzubauen, die die Umweltbelastung von Software adressieren. Der Fokus dieser Regeln liegt dabei auf dem Energieverbrauch der Software, dieser ist stark abhängig von vielen Faktoren. Allerdings lassen sich die meisten dieser Faktoren, wie beispielsweise die verwendete Programmiersprache, in laufenden Projekten gar nicht oder nur mit Hürden anpassen.

Green IT umfasst einen sehr großen Themenbereich und die Effizienz von Code selbst spielt eher eine untergeordnete Rolle, vor allem im Vergleich zu anderen Energiefressern in der IT. Das BMUV definiert Green IT so:

Unter “Green IT” sind umweltverträgliche Produkte und Dienstleistungen der Informations- und Kommunikationstechnik ( IKT) sowie der Nutzung von IKT zur Umweltschonung zu verstehen. - BMUV, stand Januar 2024 [4]

Sowohl die Produkte selbst, z.B. in der Herstellung, als auch die Verwendung dieser Produkte sollten die Umwelt so wenig wie möglich belasten. Unser Ziel ist es zu überprüfen, ob mit Hilfe der statischen Code Analyse der Umwelteinfluss, der durch die Verwendung eines Produkts (Software) entsteht, reduziert werden kann.

Wie bereits erwähnt basiert die statische Code Analyse auf verschiedenen Regeln, die “schlechten” Code erkennen und Verbesserungen vorschlagen. Die Frage ist also: Wie lassen sich Regeln definieren, mit denen die Umweltbelastung verringert werden kann? Eine der einfachsten Möglichkeiten ist für ähnliche Implementierungen (siehe Beispiel oben) die Anzahl der durchlaufenen CPU-Zyklen zu vergleichen, weniger Zyklen gleich weniger Energieverbrauch. Eine weitere Möglichkeit bietet die Verwendung effizienterer Datenstrukturen zum (zwischen-) Speichern von Daten. Außerdem können Regeln definiert werden, die zu einer effizienteren Nutzung des Netzwerks führen.

• Weniger CPU-Zyklen bedeuten, dass die Software weniger Rechenoperationen durchführen muss, was zu einem insgesamt geringeren Energieverbrauch führt.
• Effizientere Datenstrukturen verringern den Energieverbrauch, da sie weniger Speicherplatz benötigen, die Rechenoperationen optimieren und die Zugriffs- und Suchzeiten verbessern.
• Verbesserte Netzwerklast führt zu einem geringeren Stromverbrauch, da weniger Daten übertragen werden und somit weniger Energie für die Datenübertragung benötigt wird.

Es lassen sich also hauptsächlich Regeln definieren, die Code so umgestalten, dass in diesen drei Kategorien weniger Energie verbraucht wird.

Ursprüngliche Anwendungsbereiche der statische Code Analyse wie Security oder Bug Detection haben im Vergleich zur Green IT einen entscheidenden Vorteil, für diese Bereiche lassen sich Regeln, nach dem bereits erklären Muster, einfach definieren. Das liegt vor allem daran, dass der Fehler hier tatsächlich in den einzelnen Codeabschnitten/-zeilen selbst liegt.

In der Green IT ist das schlicht nicht der Fall, Codeabschnitte/-Zeilen verbrauchen zunächst keine Energie, dafür aber die Ausführung dieser. Der Energieverbrauch passiert zur Laufzeit, dementsprechend ist das auch der größte Hebel für umweltfreundlichere Software. Zur Laufzeit lassen sich dann auch weitere Variablen besser überwachen und anpassen. Beispielsweise der Strommix, denn Energieverbrauch ist nicht gleich Umweltbelastung, wenn der verwendete Strom hauptsächlich aus Erneuerbaren besteht, ist das CO2 Äquivalent der verbrauchten Energie sehr gering und damit auch die Umweltbelastung. Trotzdem ist es wichtig, den Energieverbrauch so gering wie möglich zu halten, da der grüne Strom an anderer Stelle auch verwendet werden kann. Diese und viele weitere Variablen können in einer statischen Code Analyse gar nicht betrachten, geschweige denn verbessert werden.

Mit statischer Code Analyse wird der Code also nicht automatisch grüner. Doch wir wollen auch anhand von existierenden Tools und Regeln, die Green IT Regeln implementieren, überprüfen, ob sich eine tatsächliche Verbesserung feststellen lässt. Und die wichtige Frage beantworten: Ist die statische Code Analyse nur ein Mittel, um sich selbst ein Green IT Siegel zu geben?

Standards und Regelwerke

Zunächst werfen wir noch einen kurzen Blick auf die Standards und Regelwerke, von denen die Regeln der statischen Code Analyse stammen.

Die Regeln der statischen Code Analyse beruhen in den meisten Fällen auf verschiedenen Standards. Im Bereich der Green IT existieren relativ wenige Standards, allerdings wird das Thema immer wichtiger und die Standards vielzähliger. Wichtige Standards, im Themengebiet der Green IT sind: CISQ ASCGM [5], CNUMR [6]], ISO 14001 [7] und ISO 14062 [8]. Wobei die beiden ISO-Standards nicht explizit auf den Umwelteinfluss von Software eingehen, sondern allgemeine Richtlinien für die Entwicklung grüner Produkte bieten. Darüber hinaus gibt es weitere wichtige Standards, die keinen expliziten Fokus auf Green IT haben und trotzdem die Effizienz von Software verbessern. Dazu gehören SEI CERT [9], MITRE CWE [10] und ISO 5055 [11]. Aus diesen und weiteren Standards lassen sich Regeln für die statische Code Analyse extrahieren. Dabei handelt es sich meistens um eine Interpretation der Standards, was oft zu unterschiedlichen Auslegungen derselben Standards durch unterschiedliche Regelverfasser führt. Die Grundidee bleibt dabei unverändert, aber diese Tatsache erschwert den direkten Vergleich zwischen Regelwerken. Das bedeutet auch, dass die verfügbaren Tools nur schwer miteinander verglichen werden können. Da wir hier die statische Code Analyse im Zusammenhang mit Green IT betrachten wollen bietet es sich aber an, Tools zu verwenden, die bereits Green IT Regeln implementieren.

Tools

Da das Thema der statischen Code Analyse bereits seit so langer Zeit existiert, gibt es dementsprechend viele Tools, die diese anbieten. Natürlich muss das Tool auch zum Projekt passen, allgemein gilt: Je mehr Regeln ein Tool anbietet, desto höher ist die Wahrscheinlichkeit, dass auch Regeln im Themengebiet der Green IT dabei sind. Eines der bekanntesten und größten Tools ist SonarQube, welches über die statische Code Analyse hinaus weitere Quality of Life Features bietet. Unter anderem eine graphische Oberfläche (über den Browser erreichbar), eine Vielzahl von Plugins, die Möglichkeit Regeln für einzelne Projekte zu aktivieren / deaktivieren und ist für viele IDEs als Plugin verfügbar [12]. Aufgrund dieser Vielseitigkeit wird im Folgenden vor allem die statische Code Analyse über SonarQube im Vordergrund stehen. SonarQube selbst bietet zunächst keine expliziten Regeln im Themenbereich Green IT an, allerdings lassen sich durch die Plugins leicht neue Regeln hinzufügen. Eines dieser Regelwerke ist ecoCode [13] (von CNUMR), dieses bietet explizit Regeln an, die die Effizienz und damit die Umweltbelastung von Software verbessern sollen.

Ein weiteres, nur kommerziell erhältliches, Tool ist CAST Highlight [14]. Dieses bietet weitere Funktionen an, die SonarQube nicht hat, wie beispielsweise einen Vergleich zu anderen Unternehmen. Allerdings handelt es sich hierbei eher um ein Management Tool zur Bewertung der Code Base. In CAST Highlight werden beispielsweise keine genauen Angaben gemacht, in welcher Zeile sich ein Fehler befinden, sondern lediglich die Datei genannt. Das ermöglich Features wie den Vergleich zu anderen Unternehmen. Da CAST Highlights ein kommerzielles Tool ist, wird im Folgenden der Fokus auf SonarQube liegen.

Anwendungsbeispiel - SonarQube mit ecoCode

Das Anwendungsbeispiel erfolgt mit SonarQube und für die Green IT Regeln wird das Plugin ecoCode verwendet. Als Code Base wird das Microservices Demo Projekt “Online Boutique” von Google verwendet. Da wir eine statische Code Analyse durchführen, ist es vollkommen ausreichend, das Projekt einfach nur herunterzuladen. Das verwendete Setup für SonarQube ist auf GitHub verfügbar unter: GitHub Setup [15] zusammen mit den Installationsanweisungen für ecoCode und SonarLint. Dasselbe Setup kann aus der Dokumentation von SonarQube selbst erstellt werden und ist für eine Verwendung in einem echten Projekt nicht gedacht.

Fig 1: Übersicht über die SonarQube Projekte

Nachdem das Setup fertig ist, kann jetzt die statische Code Analyse starten. Da wir hier die statische Code Analyse im Zusammenhang mit Green IT betrachten, wird den default Regeln von SonarQube hier keine große Beachtung geschenkt. Stattdessen liegt der Fokus auf den Green IT Regeln von ecoCode, eine Auflistung dieser kann hier gefunden werden: ecoCode Regeln [16]. Bei genauerer Betrachtung der ecoCode Regeln zeigt sich schnell ein Problem: in der Praxis achten die meisten Entwickler bereits auf die Regeln, welche eine reelle Auswirkung auf die Effizienz der Software haben. Und viele der anderen Regeln sind nicht besonders hilfreich. Darüber hinaus ist die Methodik, den Energieverbrauch vor und nach Anwendung einer Regel zu messen, aus mehreren Gründen fragwürdig. Zum einen ist der Einfluss, den die statische Code Analyse auf den Energieverbrauch haben kann, vernachlässigbar. Außerdem bedeutet Energieverbrauch nicht gleich Umweltbelastung, auch wenn es aktuell natürlich besser ist weniger Energie zu verbrauchen, da die Methoden zur Messung der CO2 Äquivalente zur Laufzeit noch in den Kinderschuhen stecken. Zum anderen muss man die Fragen stellen auf welchem System wurde getestet, welcher Compiler wurde verwendet oder wie genau die Messungen des Energieverbrauchs erfolgen. Das Bedeutet, dass die statische Code Analyse in der Green IT allenfalls zur Unterstützung eingesetzt werden kann. Natürlich handelt es sich bei ecoCode ebenfalls um einen sehr frühen release, allerdings ist es fragwürdig, ob statische Code Analyse aus den genannten Gründen irgendwann wirklich zu einer Verbesserung der Umweltbelastung beitragen kann.

Die Ausführung des SonarQube Scans mit den Regeln von ecoCode auf dem “micorservices-demo” Projekt findet insgesamt 15 Fehler im Bereich Green IT (ecoCode Regeln). Dargestellt sind der Name des Fehlers, wie oft der Fehler vorgekommen ist (#), warum das als Fehler markiert ist (Problem) und der Lösungsvorschlag.

Zu der Analyse der Ergebnisse sollte man zunächst wissen, dass das “micorservices-demo” Projekt ungefähr 15.000 Zeilen groß ist. Die hier gefundenen 15 Zeilen mit Green IT-Fehlern stellen also gerade einmal 0,1% des gesamten Codes dar. Insgesamt findet SonarQube ungefähr 1.100 Fehler, allerdings ist es wichtig hier zu erwähnen, dass es sich um ein Demo Projekt handelt und einige der Fehler daraus resultieren. Von den 15 gefundenen Green IT-Fehler sind (siehe Tabelle) 6 Fehler die Verwendung von globalen Variablen, das lässt sich nur leider oft nicht vermeiden. Ein weiterer erkannter Fehler, der sich nicht immer vermeiden lässt, ist die Verwendung von i++, da die alternative Schreibweise ebenfalls nicht immer anwendbar ist, wie Anfangs bereits erläutert. Aber nicht alle gefundenen Fehler sind kritisch zu betrachten, beispielsweise der Funktionsaufruf in der Schleifendeklaration oder die Deklaration nicht verwendeter Variablen sind einfach zu vermeiden. Allerdings sollten diese Regeln auch außerhalb der Green IT beachtet werden. Die Verkettung von Strings über das Plussymbol wird von aktuellen Java Compilern bereits gleich übersetzt wie die Verkettung über den StringBuilder, allerdings nicht innerhalb von Schleifen, daher diese Regel [2].

nsgesamt kann man sagen, dass das Ergebnis des Scans mit den zusätzlichen ecoCode Regeln eher ernüchternd ist. Das Projekt ist nicht optimiert für Green IT und trotzdem werden nur 15 Fehler gefunden, von denen ein großer Teil nicht vermeidbar ist. Und die Regeln, die tatsächlich angewendet werden sollten, gelten auch außerhalb der Green IT als Best Practices. Darüber hinaus muss man die Frage stellen, wie groß die zusätzliche Umweltbelastung von einzelnen, zusätzlichen Variablendeklarationen (Beispiel String Verkettung oder i++) tatsächlich ist. Den größten Effekt hat die Anpassung dieser 15 Fehler auf den Energieverbrauch mit aller Wahrscheinlichkeit nicht. Es bestätigt sich die Vermutung, dass die statische Code Analyse nicht das richtige Mittel für die Verbesserung der Green IT ist.

Fazit

Es bleibt dabei: die statische Code Analyse ist ein wichtiges Werkzeug zur Entwicklungszeit; die Wichtigkeit wird aber durch die Berücksichtigung von Green IT-Aspekten nicht erhöht. Aus verschiedenen Gründen kann die statische Code Analyse meiner Meinung nach keinen Beitrag zu Green IT leisten. Es gibt schlicht zu wenige Überschneidungen von Variablen, die mit der statischen Code Analyse justiert werden können und gleichzeitig in der Green IT eine Rolle spielen. Wenn man so wie so statische Code Analyse in einem Projekt verwendet, kann es nicht schaden — insofern die Möglichkeit besteht — auch Green IT Regeln einzubinden. Allerdings gibt es deutlich wirkungsvollere Maßnahmen, die zur Laufzeit ergriffen werden können. Hier sollte man nach dem Pareto Prinzip arbeiten und sich auf diejenigen Maßnahmen konzentrieren, die den größten Einfluss auf die Umweltbelastung von Software ausüben. Eine Tatsache ist, dass es aktuell weit größere Probleme in der Ausführung von Software gibt als 2 CPU-Zyklen mehr oder weniger. Ein guter Anfang für den Einstieg in das Thema Green IT ist der Talk “Patterns of Sustainability - Going green in IT” von Uwe Friedrichsen [17]. Hier werden verschiedene Patterns erklärt, mit denen man Software und die Entwicklung dieser grüner gestalten kann.

[1]: How Has Static Code Analysis Changed Through the Years?, https://blog.ndepend.com/static-code-analysis-changed-years/
[2]: We Don’t Need StringBuilder for Simple Concatenation: https://dzone.com/articles/string-concatenation-performacne-improvement-in-ja [3]: i-SCOOP: The impact of growing IT sector electricity demand, https://www.i-scoop.eu/sustainability-sustainable-development/it-sector-electricity-demand/ [4]: Green IT, https://www.bmuv.de/themen/nachhaltigkeit/konsum-und-produkte/produktbereiche/green-it
[5]: CISQ AUTOMATED SOURCE CODE GREEN MEASURE: https://www.it-cisq.org/wiki/cisq-automated-source-code-green-measure/
[6]: Conception Numerique Responsible: https://collectif.greenit.fr
[7]: ISO 14001: https://www.umweltdatenbank.de/cms/lexikon/35-lexikon-i/743-iso-14001.html
[8]: ISO 14062: https://www.umweltdatenbank.de/cms/lexikon/35-lexikon-i/2046-iso-14062.html
[9]: SEI CERT Coding Standards: https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards
[10]: CWE Top 10 KEV Weaknesses: https://cwe.mitre.org
[11]: ISO/IEC 5055:2021: https://www.iso.org/standard/80623.html
[12]: SonarQube: https://docs.sonarsource.com/sonarqube/latest/
[13]: ecoCode: https://github.com/green-code-initiative/ecoCode
[14]: CAST Highlight: https://www.castsoftware.com/highlight
[15]: Companion Gitlab Repository: https://gitlab.com/envite-consulting/sustainable-software-architecture/blog-article-static-code-analysis [16]: ecoCode Rules: https://github.com/green-code-initiative/ecoCode/blob/main/RULES.md
[17]: Uwe Friedrichsen: Patterns of sustainability - Going green in IT: https://speakerdeck.com/ufried/patterns-of-sustainability-going-green-in-it

• Sustainability
• Green IT
• Statische Codeanalyse
• Nachhaltigkeit