Die Platzierung der geschweiften Klammer verstößt gegen Regel 1.3b von BARR-C:2018, nach der geschweifte Klammern alleine in einer Zeile stehen sollen. (Bild: Hitex)
Die Break-Anweisung in Zeile 31 beginnt nicht in derselben Spalte wie das zugehörige Case-Label. Dies verletzt die Regel in Abschnitt 8.3a des Codier-Standards BARR-C:2018. Durch diese Regel sollen fehlende Break-Anweisungen auffallen. Hitex
Die BARR-Regeln zielen in erster Linie auf den Programmierstil ab, also beispielsweise auf die Art und Weise, wie Variablen- oder Funktionsnamen gebildet oder wie die geschweiften Klammern gesetzt werden sollen. Dies dient der Lesbar- und Verständlichkeit von Software und beugt dadurch Fehlinterpretationen vor. Dies kann tatsächliche Defekte in der Software vermeiden – der Hauptnutzen jedoch ist die Wartbarkeit und Portabilität der Software.
Viele Unternehmen haben bereits eigene Regeln für den Programmierstil erstellt, wobei es häufig Unstimmigkeiten gibt, beispielsweise wie geschweifte Klammern zu setzen sind. Die genaue Ausprägung der Regeln ist dabei aber nicht das Entscheidende, sondern dass ein einheitlicher Programmierstil entsteht. Da die proprietären Regeln für den Programmierstil von Unternehmen zu Unternehmen differieren, kann ein Off-the-Shelf-Werkzeug diese nicht ohne Anpassung prüfen. Deshalb erfordert die Konformitätsprüfung dann normalerweise einen aufwändigen manuellen Review.
Entscheidet sich ein Unternehmen mit den BARR-Regeln zu arbeiten, entfällt dieser Aufwand, denn mit Eclair lassen sich über 100 BARR-Regeln automatisiert prüfen. Falls Unternehmen die BARR-Regeln übernehmen, kann dadurch der große Aufwand für manuelle Überprüfung des Programmierstils größtenteils eingespart werden. Außerdem weist Eclair auf mögliche Laufzeitfehler hin, berechnet Metriken und prüft andere Programmierregeln wie beispielsweise die Misra- und Autosar-Richtlinien.
(wi)