Prüfen von Softwarecode
Weniger Fehler mit dem richtigen Programmierstil
Fortsetzung des Artikels von Teil 1
Code automatisiert prüfen
Bei Werkzeugunterstützung zum Erzielen eines einheitlichen Programmierstils denkt ein Entwickler vielleicht zunächst an Formatierer, sogenannte »code beautifier«. Es sind Programme, die vorgegebenen Quellcode so umwandeln, dass er einem bestimmten Programmierstil entspricht. BARR empfiehlt solche Werkzeuge, beispielsweise um die richtige Einrückungstiefe herzustellen. Außerdem empfiehlt der Programmierstandard, mithilfe einer geeigneten Einstellung des Editors zu gewährleisten, dass bei Eingabe eines Tabulators dieser sofort mit der korrekten Anzahl an Leerzeichen ersetzt wird. Will ein Entwickler ein Projekt konform zu einem Programmierstil machen, kann ein Formatierer viel Arbeit einsparen. Nicht zu vergessen ist allerdings der Aufwand, den es mit sich bringt, den Formatierer für den gewünschten Programmierstil zu konfigurieren.
Jedoch ist es während der täglichen Arbeit unsinnig, immer wieder den neu geschriebenen Quellcode mittels Formatierer konform zum Programmierstil zu gestalten. Entwickler sollten den Programmierstil bereits beim Schreiben des Codes einhalten. Weiterhin können Formatierer viele Vorgaben von BARR nicht prüfen beziehungsweise umsetzen. Somit gibt BARR häufig »code review« als Methode zum Prüfen des Einhaltens der Vorgaben an. Ein Code-Review ist eine manuelle Tätigkeit und deshalb sehr aufwendig. Was eigentlich benötigt wird, ist ein statisches Analysewerkzeug, das das Einhalten der Vorgaben aus BARR automatisiert prüft und auf Verletzungen hinweist.
Jobangebote+ passend zum Thema
Ein solches Werkzeug ist das statische Code-Analyse-Werkzeug »ECLAIR« [5]. ECLAIR findet mögliche Laufzeitfehler, prüft MISRA-Regeln und berechnet Metriken. Außerdem kann ECLAIR in der Version 3.8.1 von den 79 Vorgaben zum Programmierstil in BARR 66 Vorgaben (also etwa 84 %) automatisiert prüfen. Von allen 143 Vorgaben in BARR kann ECLAIR V3.8.1 ungefähr 85 %, nämlich 121 Vorgaben prüfen. Bei manchen der stilistischen Vorgaben in BARR ist das Prüfen jedoch schwierig: Beispielsweise fordert Vorgabe 2.2.a unter anderem, dass Kommentare in korrekter Schreibweise (»proper spelling«) verfasst sind – das übersteigt die Fähigkeiten der meisten statischen Analysewerkzeuge. ECLAIR kann jedoch ein Wörterbuch verwenden, um richtig von falsch geschriebenen Worten in Kommentaren zu unterscheiden (Bild 4).
Bei manchen der Vorgaben in BARR sind statischen Analysewerkzeugen jedoch Grenzen gesetzt: Wie soll ein Werkzeug herausfinden, ob ein Kommentar die Vorgabe 2.2.c (»avoid explaining the obvious«) verletzt?
Arbeitserleichterung durch einheitlichen Programmierstil
Standards für sicherheitskritische Software fordern einen Programmierstil. Ebenso ist ein Programmierstil für nicht-sicherheitskritische Software sinnvoll: Er macht Code verständlicher und erleichtert somit ebenso das Warten und Weiterentwickeln von Code. Jedoch haben proprietäre Standards den Nachteil, dass Entwickler sie zunächst erarbeiten und dokumentieren müssen – ein erheblicher Aufwand mit entsprechender Expertise ist erforderlich. Und nicht selten führt der Prozess zu Spannungen unter den Beteiligten.
Ist ein proprietärer Standard eingeführt, erfordert das Prüfen seines Einhaltens ebenso einen großen Aufwand, denn das muss über manuelles Code-Review erfolgen. In der Regel existiert nämlich kein (Off-the-shelf)-Werkzeug, das ein Prüfen automatisieren könnte. So bietet das Verwenden eines allgemein verfügbaren Programmierstils – beispielsweise BARR – viele Vorteile: Einerseits existiert der Programmierstilstandard und ist nicht erst zu erarbeiten. Ist er als Expertenmeinung anerkannt, entfallen außerdem die Reibungen im Team über das Gestalten einzelner Vorgaben. Gibt es weiterhin ein Werkzeug für das automatisierte Prüfen der Vorgaben des Programmierstils, wird viel manueller Aufwand eingespart. Für BARR ist beispielsweise ECLAIR ein solches Werkzeug. Zu guter Letzt wird mit einem allgemein bekannten Programmierstil das Einarbeiten neuer Mitarbeiter in
ein Projekt erleichtert.
Literatur
[1] Embedded C Coding Standard by Michael Barr. Edition BARR-C:2018. www.barrgroup.com
[2] MISRA-C:2004. Guidelines for the use of the C language in critical systems. Mira Limited. Edition 2. Oktober 2004.
[3] MISRA C:2012. Guidelines for the use of the C language in critical systems.
Horiba Mira Limited. Edition 3, März 2013.
[4] Roberto Bagnara, Michael Barr, Patricia M. Hill: BARR-C:2012 and MISRA C:2012: Synergy Between the Two Most Widely Used C Coding Standards. Whitepaper. 2020.
[5] Statisches Analysewerkzeug von BUGSENG. www.hitex.de/eclair
Der Autor
Frank Büchner hat ein Diplom in Informatik und widmet sich seit vielen Jahren dem Thema Testen und Softwarequalität. Momentan arbeitet er als »Principal Engineer Software Quality« bei der Firma Hitex in Karlsruhe.
frank.buechner@hitex.de
- Weniger Fehler mit dem richtigen Programmierstil
- Code automatisiert prüfen
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Interview mit Sylvain Duranton
»Wir wollen dazu beitragen, weltweit CO2-Emissionen zu senken«
Programmieren mithilfe von Low Code
Lego für Ingenieure
Debugging von Multicore-Controllern
UDE 2021 vereinfacht Testen und Debuggen
