Schwerpunkte

Prüfen von Softwarecode

Weniger Fehler mit dem richtigen Programmierstil

16. Februar 2021, 08:00 Uhr   |  Autor: Frank Büchner | Redaktion: Tobias Schlichtmeier

Weniger Fehler mit dem richtigen Programmierstil
© Africa Studio | shutterstock.com

Diverse Standards fordern beim Entwickeln von Software das Einhalten eines Programmierstils. Oft ist er proprietär – deshalb ist das Prüfen des Einhaltens meist aufwendig. Mit dem frei verfügbaren Standard BARR-C:2018 können Softwareentwickler das jedoch automatisieren.

Unter Programmierstil ist das »Aussehen« eines Programms zu verstehen.  Beispielsweise das Setzen geschweifter Klammern, die Namensgebung von Variablen und Funktionen, die Einrückungstiefe und ähnliches. Jedoch verhindert der Programmierstil keine Programmabstürze oder sonstiges Fehlverhalten. Trotzdem ist ein einheitlicher Programmierstil innerhalb eines Projekts oder einer Organisation wichtig: Er gewährleistet, dass der Quellcode leicht verständlich ist. Dies ist essenziell für alle Beteiligten, zum Beispiel im Falle eines Reviews oder einer Inspektion. Auch bei späteren Arbeiten am Quellcode, beispielsweise Funktionserweiterungen oder Portierungen, ist ein einheitlicher Programmierstil sehr wertvoll, weil er das (Wieder-) Einarbeiten in den Quellcode erleichtert.

Praktisch alle Standards zum Entwickeln von sicherheitskritischer Software wie IEC 61508, ISO 26262, EN 50128 oder IEC 62304 fordern mehr oder weniger nachdrücklich das Einhalten eines Programmierstils – ein solcher wird in diesem Artikel vorgestellt.

Der Programmierstandard BARR-C:2018

Im Folgenden werden Vorgaben zum Programmierstil aus dem »Embedded C Coding Standard BARR-C:2018« (kurz BARR) von Michael Barr [1] betrachtet. Der Programmierstandard ist kostenlos im Internet verfügbar. BARR enthält nicht nur Vorgaben zum Programmierstil, sondern ebenso Vorgaben, die die Sprache »C« einschränken oder den Entwicklungsprozess betreffen. BARR umfasst insgesamt 143
Vorgaben, davon betreffen mehr als die Hälfte, nämlich 79 Vorgaben, den Programmierstil.

BARR-Vorgaben
© Hitex

Bild 1. Die Vorgeschichte der BARR-Vorgaben.

BARR hat eine Vorgeschichte (Bild 1): 2009 wurde der »Netrino’s Embedded C Coding Standard« publiziert, der im Jahr 2013 unter dem Namen »Embedded C Coding Standard« erneut veröffentlich wurde. Alle wurden von Michael Barr beziehungsweise der Barr Group herausgegeben. Die erste Edition von BARR (Netrino von 2009) berücksichtigt MISRA-C:2004 [2], die aktuelle Edition (BARR-C:2018) berücksichtigt MISRA C:2012 [3].

Bereits in der Einleitung führt BARR aus, dass die Absicht des Programmierstandards ein Verringern der Anzahl an Programmierfehlern in Embedded-Software ist. Das betrifft sowohl die spracheeinschränkenden als auch die stilistischen Vorgaben. Hierbei sollen nicht die persönlichen Vorlieben der Autoren des Standards zum Tragen kommen. Vielmehr wurde, falls mehrere alternative Vorgaben für einen bestimmten Programmieraspekt möglich waren, diejenige Alternative gewählt, die die größte Reduktion von Fehlern versprach. Das betrifft explizit Vorgaben zum Stil, beispielsweise wann und wie geschweifte Klammern zu setzen sind. Es gibt 38 Vorgaben, denen BARR ein besonderes Vermeiden von Fehlern attestiert. Sie sind mit dem Attribut »keep bugs out« gekennzeichnet. Weil Programmierer Vorgaben zum Stil oft kontrovers diskutieren, weist BARR darauf hin, dass Quellcode nicht einem Programmierer gehört, selbst wenn er ihn geschrieben hat, sondern einer Firma oder einem Auftraggeber. Außerdem seien folgende Attribute von Quellcode wichtiger als die Vorlieben eines Programmierers:

  • Lesbarkeit
  • Verständlichkeit
  • Zuverlässigkeit
  • Effizienz
  • Portierbarkeit

Alle Vorgaben von BARR sind in Abschnitten zusammengefasst, wobei die einzelnen Vorgaben mit Kleinbuchstaben bezeichnet sind, immer beginnend bei a. Um eine Vorgabe eindeutig zu bezeichnen, ist immer die Nummer des Abschnitts anzugeben. Beispielsweise bezeichnet 6.1.e die Vorgabe aus dem Kapitel 6 (»Procedure Rules«), Abschnitt 6.1 (»Naming Conventions«), Vorgabe e, die wie folgt lautet: »No function name shall contain any uppercase letters«.

Verhältnis von MISRA und BARR

Die gute Nachricht ist: BARR hat das Ziel, kompatibel mit MISRA [3] zu sein – noch besser: BARR ergänzt MISRA sogar. Vorgaben zum Programmierstil sind praktisch nicht in MISRA enthalten. Andererseits erwartet MISRA, dass Entwickler eigene Vorgaben zum Programmierstil einsetzen, weil:

  • von MISRA anerkannt wird, dass ein einheitlicher Programmierstil die Verständlichkeit von Code fördert und
  • MISRA keine Vorgaben macht, die rein den Programmierstil betreffen.

Somit ist das Einhalten von Vorgaben zum Programmierstil für die Konformität zu MISRA eigentlich nötig.

BARR und MISRA
© Hitex

Bild 2. Leider sind nicht alle BARR-Vorgaben kompatibel zu MISRA.

Jedoch klappt es leider mit der Kompatibilität von BARR und MISRA nicht ganz. Beispielsweise schränkt die Vorgabe 1.7.d von BARR das Verwenden des Schlüsselworts »continue« ein (»it is preferred practice to avoid all use of the continue keyword«). Eine solche Einschränkung gibt es in MISRA C:2012 nicht (mehr), wohl aber in MISRA-C:2004. Weiterhin erlaubt MISRA C:2012 die Sprachstandards C90 und C99, wohingegen BARR lediglich C99 erlaubt. Ebenso sind die Schlüsselworte »auto« und »register« in BARR verboten, was in MISRA nicht der Fall ist. In Bild 2 sollte der rote Kreis, der die BARR-Vorgaben symbolisiert, eigentlich vollständig im grünen Kreis liegen, was die vollständige Kompatibilität von BARR zu MISRA symbolisieren würde.
Beim Vergleich von MISRA und BARR fällt zudem auf, dass MISRA wesentlich präziser und ausgearbeiteter ist als BARR. Von den 64 Vorgaben in BARR, die nicht den Programmierstil betreffen, haben zehn eine genaue Entsprechung in MISRA, 27 haben eine ungefähre Entsprechung, zehn sind ähnlich zu Vorgaben in MISRA und 17 haben keine Entsprechung.

Vorgaben von BARR

Die 79 Vorgaben für den Programmierstil kann man wie folgt einteilen [4]:

Zeilenlänge
Es gibt eine Vorgabe (1.2.a), die die Zeilenlänge auf 80 Zeichen begrenzt.

Horizontale Abstände
Es gibt 13 Vorgaben (Abschnitt 3.1), die das Platzieren von Leerzeichen betreffen, beispielsweise 3.1.m, nach der kein Leerzeichen vor dem Semikolon stehen soll, das eine Anweisung beendet.
Der Tabulator ist verboten (3.5.a).
Es gibt fünf Vorgaben, die Ausrichtung (alignment) betreffend, beispielsweise 3.2.b, nach der die Namen von Strukturkomponenten aufeinander auszurichten sind.
Es gibt drei Vorgaben, die Einrückungen betreffen, alle in Abschnitt 3.4. Beispielsweise 3.4.a, wonach vier Zeichen pro Einrückungsebene einzurücken sind.

Vertikale Abstände
Es gibt sechs Vorgaben, die den Zeilenumbruch betreffen, beispielsweise 3.3.a, die höchstens eine Anweisung pro Zeile erlaubt.

Werkzeug ECLAIR
© Hitex

Bild 3. Das Werkzeug ECLAIR moniert eine öffnende geschweifte Klammer, die nicht allein in einer Zeile steht (1TBS).

Anordnung des Codes
Es gibt sechs Vorgaben, die das weitere Anordnen des Codes betreffen, beispielsweise 1.3.b, wo es um das Setzen der Klammern geht. Anhänger des »One True Brace Style« oder 1TBS müssen jetzt tapfer sein, denn 1.3.b besagt, dass eine öffnende geschweifte Klammer allein in einer Zeile stehen muss. Eine dazugehörige, schließende geschweifte Klammer muss darunter ebenfalls in einer eigenen Zeile stehen, und zwar in der gleichen Spalte wie die Öffnende. Die Vorgabe hat das Attribut »keep bugs out«, womit BARR besonders fehlervermeidende Vorgaben kennzeichnet. Bei 1TBS steht die öffnende geschweifte Klammer am Ende der Zeile, beispielsweise nach der Entscheidung einer if-Anweisung (Bild 3).

Namensgebung
Es gibt 25 Vorgaben zur Namensgebung. Sie betreffen die Namen von Modulen, Namen von Funktionen und Namen von Variablen. In BARR besteht ein Modul aus einer Quelldatei und einer Header-Datei. Hierbei geht es unter anderem um das Verwenden von Unterstrichen und Groß- und Kleinbuchstaben. Genauso jedoch wie in 7.1.e um die Länge von Variablennamen, die nicht kleiner als drei Zeichen sein darf. Vorgabe 7.1.j fordert beispielsweise, dass alle globalen Variablen mit dem Buchstaben g beginnen.

Abkürzungen
Es gibt zwei Vorgaben zu Abkürzungen und Akronymen, beide in Abschnitt 1.5. So sind laut Vorgabe 1.5.a lediglich allgemein bekannte Abkürzungen zu verwenden.

Kommentare
Es gibt elf Vorgaben zu Kommentaren – gemäß 2.2.c soll man es beispielsweise vermeiden, das Offensichtliche zu kommentieren.

Quelldateien
Es gibt sechs Vorgaben zu Quelldateien, alle in Abschnitt 4.3. Beispielsweise fordert 4.3.f, dass keine Quelldatei eine andere Quelldatei inkludieren darf.
Alle Vorgaben des Programmierstandards BARR erachtet der Standard selbst als zwingend einzuhalten. Manche Vorgaben, bei denen es um numerische Größen wie Zeilenlänge und Einrückungstiefe geht, darf der Programmierer an die Erfordernisse des Projekts anpassen. Wird ansonsten gegen eine Vorgabe verstoßen, so ist der Verstoß vom »project manager« zu genehmigen und mit Namen und Begründung als Kommentar im Quellcode zu hinterlegen.

Seite 1 von 2

1. Weniger Fehler mit dem richtigen Programmierstil
2. Code automatisiert prüfen

Auf Facebook teilenAuf Twitter teilenAuf Linkedin teilenVia Mail teilen

Das könnte Sie auch interessieren

UDE 2021 vereinfacht Testen und Debuggen
Lego für Ingenieure
»Wir wollen dazu beitragen, weltweit CO2-Emissionen zu senken«

Verwandte Artikel

Hitex GmbH