PROGRAMMIERUNG / CLEAN CODE - Kapitel
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
5.
Kapitel
PROGRAMMIERUNG
/
CLEAN
CODE
So#waretechnik
Prof.
Dr.
Wolfgang
Schramm
Übersicht
1
1. Einführung in das Software Engineering
2. Softwareprozesse
3. Anforderungsanalyse und -Spezifikation
4. Softwareentwurf
5. Programmierung
6. Software-Qualitätssicherung und -Prüfung
7. Konfigurationsverwaltung
8. Software-Wartung
Implementierung
2
Idee!!!
Entwurf von Algorithmus
und Datenbank,
Hardware Konfiguration
Benutzung System-Entwicklung
Problemdefinition,
funktionale Analyse
System-Analyse
Programmierung
3
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]
Wichtige Eigenschaften von
Programmiersprachen
4
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.
Inhalt
5
1. Motivation
2. Beispiele und Empfehlungen
3. Ursachen und Konsequenzen
4. Abhilfe schaffen am Beispiel
Antonio Fiol
http://www.flickr.com/photos/fiol/3455863437
Fragerunde
6
o Was fällt Ihnen zu dem
Begriff "Code-Qualität" ein?
o Was hat positiven, was
negativen Einfluss auf die
Qualität von Code?
o Warum?
Suriya Donavanik
http://www.fotopedia.com/items/3n79pfv8fbe9h-4EWWh9Maaxs
Wie kommt es überhaupt zu schlechtem Code?
7
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.
Inhalt
8
1. Motivation
2. Beispiele und Empfehlungen
3. Ursachen und Konsequenzen
4. Abhilfe schaffen am Beispiel
Antonio Fiol
http://www.flickr.com/photos/fiol/3455863437
Regeln für die Programmierung 1/2
9
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).Regeln für die Programmierung 2/2
10
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 ….Programm-Dokumentation
11
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.Kommentare – Arten
12
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.Kommentare – Beispiel Kopfkommentar
13
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).Robuste Programme
14
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%Werkzeuge zur Programmentwicklung
15
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.Ein Beispiel für schlechten Code
16
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?Ein Beispiel für schlechten Code: Fehlercodes
17
Die bessere Variante:Ein Beispiel für schlechten Code: null als
Parameter
18
• Eine Methode akzeptiert zwei Punkte 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:Ein Beispiel für schlechten Code: null als
Parameter
19
• Eine Methode akzeptiert zwei Punkte als Parameter:
• Was passiert,
blem
wenn sie
b le ib t mit
b e null
s te aufgerufen
h e n : wird:
Das Pro r ausgelöst
in e E xc e p ti o n /e in Fe h le
Es wird e
• Eine Möglichkeit, mit diesem Parameter umzugehen:
à Lösung: Disziplin – Pa ra m e ter!
Übergebe n S ie nie n u ll a ls
• Eine andere Möglichkeit, mit diesem Parameter umzugehen:Ein Beispiel für schlechten Code: Output-
Parameter
20
o Was vermuten Sie, tut die folgende Programmzeile:
…wenn Sie das Popup dazu sehen?
• Wie sollte diese Zeile stattdessen geschrieben werden?Ein Beispiel für schlechten Code: Output-
Parameter
21
o Was sagt Ihnen die folgende Programmzeile:
…wenn Sie das Popup dazu sehen?
à Empfehlung: durch
e id e n S ie S e ite n e ffe k te
Verm
Output-Parameter!
e n a n e in e m O b je k t s o llte n nur
à Zustandsänderung je kts v o rg e n ommen
durch Method e n d ie s e s O b
werden!
• Wie sollte diese Zeile geschrieben sein?Trennen von Anweisungen und Abfragen
22
• Was tut (vermutlich) die Methode set im folgenden Beispiel:
• Empfehlung:
Trennen Sie immer Anweisungen von Abfragen, zum Beispiel:Boole'sche Parameter vermeiden
23
• 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!Diskussion
24
o 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
Arto Teräs
http://ajt.iki.fi/travel/debconf5/page2.htmlKommentare vs. guter Code
25
• Welches Programm würden Sie lieber lesen,
dieses hier:
… oder dieses:Pfadfinder-Regel
26
Hinterlassen Sie
Programmcode immer etwas
aufgeräumter als Sie ihn
vorgefunden haben!
frei nach
Robert Stephenson Smyth Baden-
PowellInhalt
27
1. Motivation
2. Beispiele und Empfehlungen
3. Ursachen und Konsequenzen
4. Abhilfe schaffen am Beispiel
Antonio Fiol
http://www.flickr.com/photos/fiol/3455863437Fragerunde
28
o Welche Auswirkungen kann
(besonders) guter Code
haben?
o Welche Auswirkungen kann
(besonders) schlechter Code
haben?
Suriya Donavanik
http://www.fotopedia.com/items/3n79pfv8fbe9h-4EWWh9MaaxsWie kommt es überhaupt zu schlechtem Code?
29
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
vergessenWie kommt es zu schlechtem Code:
Metapher
30
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.jpgFragerunde
31
o Wie misst man die Qualität
von Code?
Suriya Donavanik
http://www.fotopedia.com/items/3n79pfv8fbe9h-4EWWh9Maaxs32
Inhalt
33
1. Motivation
2. Beispiele und Empfehlungen
3. Ursachen und Konsequenzen
4. Abhilfe schaffen am Beispiel
Antonio Fiol
http://www.flickr.com/photos/fiol/3455863437
Motivation ■■■ Beispiele und Empfehlungen ■■■ Ursachen und Konsequenzen ■■■ Abhilfe schaffenFragerunde
34
o Was kann man gegen
schlechten Code tun?
Suriya Donavanik
http://www.fotopedia.com/items/3n79pfv8fbe9h-4EWWh9Maaxs
Motivation ■■■ Beispiele und Empfehlungen ■■■ Ursachen und Konsequenzen ■■■ Abhilfe schaffenRefactoring am Beispiel 36
37
F R A G E N photography: woodleywonderworks
http://www.flickr.com/photos/wwworks/2350106729
art work: Peter KaiserQuellen
38
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, 2002Sie können auch lesen
