Coding-Guidelines: Sind Programmierrichtlinien Fluch oder Segen?

Ob Safety- oder Security-Richtlinien wie MISRA:C oder einheitliche Guidelines für hauseigenen Programmcode: Es gibt viele Gründe, warum Firmen von ihren Softwareentwicklern verlangen, sich an Programmierrichtlinien zu halten. Aber ist das auch immer sinnvoll?

Anbieter zum Thema

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

MicroConsult Microelectronics Consulting & Training GmbH

Der Code, der von vielen Entwicklern abgeliefert wird, sieht alles andere als schön aus. In Vorträgen, Artikeln und Büchern wird immer darauf hingewiesen, dass die Qualität des Codes ein entscheidender Faktor für den Erfolg des Projektes ist. Deshalb wird immer wieder versucht, Regularien einzuführen, die die Codequalität verbessern. Ein Ansatz, um die Qualität des Codes zu sichern, ist das Verwenden von Programmierrichtlinien.

Viele Firmen haben keine Richtlinien, wie Code auszusehen hat. Jeder Entwickler entscheidet das für sich selbst. Vorstöße einzelner Kollegen, etwas zu verbessern, werden gerne im Keim erstickt, da man dann ja etwas anders machen müsste. Andere Firmen haben zwar Richtlinien, aber derer zu viele. Das schafft Unsicherheit, da niemand weiß, an was er sich denn zu halten hat – also macht wieder jeder „seins“.

Oder aber es gibt klare Regeln, die jedoch viel zu weit gehen und den Entwickler in seiner Kreativität stark einschränken. Vermeintlich unsichere Konstrukte werden verboten, um die Sicherheit des Codes zu erhöhen. Auf der anderen Seite verhindern diese strengen Regeln, dass moderne Programmiertechniken eingesetzt werden - der Code wird unleserlich, was die Sicherheit wiederum senkt.

Gründe für die Einrichtung von Programmierrichtlinien

Um das Richtlinien-Dilemma besser zu verstehen, muss man sich erst einmal Gedanken machen, was die Gründe für die Einführung von Programmierrichtlinien sind.

1. Variante:
Die Regeln sollen helfen, eine Codebasis zu schaffen, in der sich jeder Entwickler zurechtfindet. Der Code ist gut strukturiert und einfach zu lesen. Die Zusammenarbeit der einzelnen Teammitglieder soll reibungslos funktionieren.

2. Variante:
Es wird ein strenges Regelwerk geschaffen, das alle als kritisch eingestuften Konstrukte verbietet, in dem Glauben, dass dann jeder, der im Projekt sitzt, programmieren kann. Ausbildung wird durch Regeln ersetzt – die Entwicklung kann besser in Billiglohnländer ausgelagert werden.

Variante zwei wird nicht funktionieren - Ausbildung lässt sich nicht durch Regeln ersetzen. Probleme in der Softwareentwicklung sind nicht die Folge von zu wenigen Regeln, sondern von zu wenig Ausbildung. Das Hauptproblem ist, dass die Komplexität von Software in den klassischen Industriezweigen unterschätzt wird. Das Management vertritt häufig die Meinung, was nichts wiegt, ist nichts wert. Dementsprechend wird viel zu wenig Wert auf die Grundlagen gelegt. Ingenieure werden einfach vor die Entwicklungsumgebung gesetzt, ohne die Grundlagen richtig erlernt zu haben.

Demnach muss vor jeder Regel erst einmal eine sorgfältige Ausbildung kommen. Das klingt teuer, ist aber in der Summe die kostengünstigste Lösung. Programmierrichtlinien können Ausbildung nicht ersetzen. Sie sind eine Ergänzung, um die Teamarbeit zu verbessern.

Ein weiterer wichtiger Punkt ist die Motivation der Entwickler. Wenn der Sinn der Regeln nicht klar ist, wird es immer auch Verstöße geben. Im Endeffekt sollte der Entwickler der Hauptnutznießer der Regeln sein. Andernfalls haben die Regeln ihren Sinn verfehlt und werden nicht akzeptiert.

Zudem sollte die Menge der Regeln überschaubar sein (z.B. Vorder- und Rückseite eines A4-Blattes). Wenn geblättert werden muss, wird eher nicht gelesen. Regeln, die die Formatierung des Codes betreffen, müssen automatisch geprüft werden. Ein Check-in darf mit Regelverstoß nicht möglich sein.

Fazit

1. Vor dem Einsatz von Programmierregeln sollte zuerst die Zielsetzung überprüft und gegebenenfalls korrigiert werden.

2. Ohne ausreichende Ausbildung der Entwickler werden auch die besten Regeln nichts retten können.

3. Auf wenige, aber sinnvolle Regeln beschränken.

Der Autor

* Dipl.-Ing. Frank Listing ist seit 2002 Trainer und Projektcoach bei der MicroConsult GmbH mit dem Schwerpunkt Microsoft-Plattformen, objektorientierte Programmierung und Testen von Embedded-Systemen und u.a. fachlich für das Thema .NET verantwortlich.

(Dieser Beitrag wurde mit freundlicher Genehmigung des Autors dem Tagungsband Embedded Software Engineering Kongress 2018 entnommen.)

(ID:45719924)