Softwaretechnik

Prof.Dr.WolfgangSchramm

PROGRAMMIERUNG/CLEANCODE5.Kapitel

1

Übersicht

1. Einführung in das Software Engineering

2. Softwareprozesse3. Anforderungsanalyse und -

Spezifikation4. Softwareentwurf5. Programmierung6. Software-Qualitätssicherung und

-Prüfung7. Konfigurationsverwaltung8. Software-Wartung

2

Implementierung

Benutzung

Idee!!!

Problemdefinition, funktionale

Analyse

System-Entwicklung

Entwurf von Algorithmus und Datenbank,Hardware Konfiguration

System-Analyse

3

Programmierung

Programming is a craft. It is dependent on individual skill, attention to detail, and knowledge of how to use available tools in the best way. Craftsmen must know their materials, understand the principles of their craft and learn by experience. Thus, programmers must understand both host and target computer systems, must know some theory of programming and must practice programming.

[Som06]

4

Wichtige Eigenschaften von Programmiersprachen

o Strukturelemente zur Konstruktion modularer Programmeinheiten.o Trennung von Schnittstelle und Implementierung.o Mächtiges Typsystem mit strenger Typprüfung.o Syntax, die zur Lesbarkeit des Codes beiträgt.o Automatische Zeigerverwaltung.o Ausnahmebehandlung.

5

Inhalt

1. Motivation2. Beispiele und Empfehlungen3. Ursachen und Konsequenzen4. Abhilfe schaffen am Beispiel

6

Fragerunde

¨ Was fällt Ihnen zu dem Begriff "Code-Qualität" ein?

¨ Was hat positiven, was negativen Einfluss auf die Qualität von Code?

¨ Warum?

7

Wie kommt es überhaupt zu schlechtem Code?

o Zu Beginn eines Projekts "auf der grünen Wiese" ist die Code-Qualität (meist) gut und sauber (clean).

o Schlechter wird die Code-Qualität von alleine:¤ Software(-Lösungen) wachsen und werden zunehmend

komplexer.¤ Änderungen schaden der (initial klaren) Struktur.¤ Zeitdruck führt zu nicht-idealen Lösungen.¤ Kurzfristige Lösungen werden nie verbessert.¤ Programmteile werden zweckentfremdet.¤ Kommentare werden nicht aktualisiert.¤ Dinge/Gründe, die zu Beginn noch "klar waren", werden

vergessen.

8

Inhalt

1. Motivation2. Beispiele und Empfehlungen3. Ursachen und Konsequenzen4. Abhilfe schaffen am Beispiel

9

Regeln für die Programmierung 1/2

o Richtlinien¤ Wie sind die Bezeichner zu wählen.¤ Wie ist das Layout zu gestalten.¤ Wie sind die Schnittstellen zu gestalten (globale Variablen, Reihenfolge

der der Parameter).¤ Was/Wie muss kommentiert werden.

Beispiele: GNU Coding Standard, Java Coding Style Guide¤ Umfang von Hauptprogramm, Prozeduren, Paketen in LOC.¤ Anzahl von Attributen pro Klasse.¤ Anzahl öffentlicher Methoden pro Klasse.¤ Umfang einer Daten (Klasse).

10

Regeln für die Programmierung 2/2

o Ratschläge (nach Fairley [Fai85])¤ Don‘t be to clever.¤ Avoid null Then-statements and Avoid Then-If-statements.¤ Don’t nest too deepley.¤ Avoid obscure side effects .. . Avoid side effects.¤ Don’t suboptimize.¤ Routines having more than five parameters?¤ Don’t use an identifier for multiple purposes.

o Ergänzung¤ Logische Aussagen so einfach wie möglich halten.¤ Text- und Zahlenliterale (außer 0 und 1) gehören nicht in das Programm.¤ Jedes Programm muss ausreichend kommentiert sein.

if not (Bildschirmausgabe or DruckerAusgeschaltet) then ….

11

Programm-Dokumentation

o Make the code as clear as possible to reduce the need for comments.

o Never repeat information in a comment that is readily available in the code.

o Where a comment is required, make it concise and complete.o Use proper grammar and spelling in comments.o Make comments visually distinct from the code.o Structure comments in headers so that the information can be

automatically extracted by a tool.

12

Kommentare – Arten

o Kopfkommentare: am Anfang von Programmeinheiten (Module, Klassen u.ä.).

o Eingeschobene Kommentare: erläutern Zeilen oder Abschnitte einer Programmeinheit.

o Erläuterungen: kurze Beschreibung – z.B. bei Deklaration oder Wertzuweisung.

13

Kommentare – Beispiel Kopfkommentar

o Verfasser und Datum.o Programmiersprache und Compiler (mit Versionsangaben).o Umgebung (verwendete System-Software).o Kurzbeschreibung.o Beziehung zu anderen Programmeinheiten (i.S.v. Benutzung).o Verweise auf externe Dokumente.o Verfasser, Datum, Anlass und Auswirkung von Änderungen (sofern

nicht durch ein eingesetztes Versionsverwaltungssystem geliefert).

14

Robuste Programme

o The degree to which a system or a component can function correctly in the presence of invalid inputs or stressful environmental conditions.

è Der Code sollte auf viele mögliche Fehlersituationen reagieren:è Fehlerhafte Bedienung durch den Anwender.è Fehlerhafte Umgebungssituation.

Anteil des Codes für Fehlerbehandlung: 25% - 50%

15

Werkzeuge zur Programmentwicklung

o Syntax-gesteuerter Editor: zum Erzeugen und Anzeigen syntaktischer Strukturen und Erkennung einfacher Fehler.

o Werkzeug, welches den Übersetzungs- und Bindeprozess steuert.o Werkzeug für die Verwaltung der Quellprogramme, auch aller

anderen Softwareeinheiten und ihrer Konfigurationen (Bsp.: make, ant).

o Werkzeuge, welche den Test unterstützen und die Testüberdeckung messen (Bsp.: JUnit).

o Werkzeug, welches den Code bezüglich der der Codierregeln prüft (Bsp.: Java CheckStyle).

o Debugger, zur Fehlersuche auf der untersten Ebene.

16

Ein Beispiel für schlechten Code

o Was stört Sie (hoffentlich) an folgendem Programmcode:

• Was können Sie tun, um solche Codefragmente zu vermeiden?

• Wie würde die Methode dann aussehen?

17

Fehlerbehandlung vom eigentlichen Ablauf trennen:

Entweder durch Exception Handler

oder

durch Behandlung der Situation außerhalb

18

Ein Beispiel für schlechten Code: Fehlercodes

Die bessere Variante:

19

Ein Beispiel für schlechten Code: null als Parameter

• Was passiert, wenn sie mit null aufgerufen wird:

• Eine Möglichkeit, mit diesem Parameter umzugehen:

• Eine andere Möglichkeit, mit diesem Parameter umzugehen:

• Eine Methode akzeptiert zwei Punkte als Parameter:

20

Ein Beispiel für schlechten Code: null als Parameter

• Was passiert, wenn sie mit null aufgerufen wird:

• Eine Möglichkeit, mit diesem Parameter umzugehen:

• Eine andere Möglichkeit, mit diesem Parameter umzugehen:

• Eine Methode akzeptiert zwei Punkte als Parameter:

21

Ein Beispiel für schlechten Code: Output-Parameter

o Was vermuten Sie, tut die folgende Programmzeile:…wenn Sie das Popup dazu sehen?

• Wie sollte diese Zeile stattdessen geschrieben werden?

22

Ein Beispiel für schlechten Code: Output-Parameter

o Was sagt Ihnen die folgende Programmzeile:…wenn Sie das Popup dazu sehen?

• Wie sollte diese Zeile geschrieben sein?

23Trennen von Anweisungen und Abfragen

• Was tut (vermutlich) die Methode set im folgenden Beispiel:

• Empfehlung:Trennen Sie immer Anweisungen von Abfragen, zum Beispiel:

24

Boole'sche Parameter vermeiden

• Was tut (vermutlich) der folgende Aufruf:…wenn Sie das Popup dazu sehen?

• Wie könnte eine bessere Lösung aussehen?Empfehlung:Verwenden Sie zwei Methoden mit aussagekräftigen Namen!

25

Diskussion

¨ Diskutieren Sie folgende Behauptungen zu Kommentaren:¤ Wenn wir uns mittels

Programmcode gut genug ausdrücken könnten, würden wir keine Kommentare brauchen

¤ Kommentare sind kein Ersatz für schlechten Code

¤ Ein Kommentar bekräftigt unsere Unfähigkeit, guten Code zu schreiben

26

Kommentare vs. guter Code

• Welches Programm würden Sie lieber lesen,dieses hier:

… oder dieses:

27Pfadfinder-Regel

Hinterlassen Sie Programmcode immer etwas aufgeräumter als Sie ihn vorgefunden haben!

frei nach Robert Stephenson Smyth Baden-Powell

28

Inhalt

1. Motivation2. Beispiele und Empfehlungen3. Ursachen und Konsequenzen4. Abhilfe schaffen am Beispiel

29

Fragerunde

¨ Welche Auswirkungen kann (besonders) guter Code haben?

¨ Welche Auswirkungen kann (besonders) schlechter Code haben?

30

Wie kommt es zu schlechtem Code:Metapher

What’s the fastest way to be done with dinner? Get up from the table and not do the clean up. When it is time to eat we just find the cleanest dishes and when dinner is over we leave the dishes dirty again. Eventually it is so hard to make dinner we outsource dinner. Sushi chefs clean as they prepare food. If you want to go fast – go as clean as you can. The only way to go fast is to go clean.

[Robert C. "Uncle Bob" Martin]

http://farm3.staticflickr.com/2485/4070664881_441658bc44_z_d.jpg

31

Fragerunde

¨ Wie misst man die Qualität von Code?

32

33

Inhalt

1. Motivation2. Beispiele und Empfehlungen3. Ursachen und Konsequenzen4. Abhilfe schaffen am Beispiel

34

Fragerunde

¨ Was kann man gegen schlechten Code tun?

36

Refactoring am Beispiel

38

Quellen

o Robert C. Martin:Clean Code: A Handbook of Agile Software Craftsmanship, Prentice Hall International, 2008

o Object Mentor:http://www.objectmentor.com/omTeam/martin_r.html

o Martin Fowler:Improving the Design of existing Code, Addison-Wesley Longman, 2002