SeminarEPMuW ENWAT

Efficient Programming - Methods and Tools
Dipl.-Inf. Martin Barbisch, Dipl.-Inf. Ursula Vollmer
2007/07/04 (08.30-11.30)
2007/07/05 (10.00-13.00)
2007/07/11 (08.30-11.30)
2007/07/12 (10.00-13.00)
1 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

Organizational
contact:
Institut für Maschinelle Sprachverarbeitung
Azenbergstr. 12
Martin Barbisch (room 3.5):
martin.barbisch@ims.uni-stuttgart.de
Ursula Vollmer (room 3.3):
ursula.vollmer@ims.uni-stuttgart.de

Overview (2007/07/04)
Object Oriented Programming

Process Models
Unified Modeling Language
Consistency

Overview (2007/07/05)
Style Guides
DRY Principle / Reuse
Orthogonality
Automation
Refactoring

Overview (2007/07/11)
Programming Languages
Editors
Version Control Systems

Overview (2007/07/12)
Creation / Adaption of Source Code

Debugging
Creation of Documentation
Testing

Motivation (Topic)
programming very complex

high danger of frustration
reliability (especially in large projects)

Motivation (Target Audience)
facilitation of large as well as small programming tasks

industry
research projects

Object
Object Oriented Programming Class
Process Models Inheritance
Unified Modeling Language Example
Consistency Polymorphy
Encapsulation
basic idea: mapping of real world in program

classification of data according to their features and possible
operations

Object
Encapsulation
Object
object structure defined by attributes (features) of its class

definition
object behavior defined by class methods
information hiding: no object may access information of
another

Object
Encapsulation
Class
grouping of objects according to similar features

Object
Encapsulation
Inheritance
inheritance of data structure (attributes) and methods

multiple inheritance: non-hierarchical exchange of attributes

Object
Encapsulation
Example: Birds

Object
Encapsulation
Example: Birds
attributes:
feet = two
beak
plumes
methods:
walk
eat

Object
Encapsulation
Example: Birds

Object
Encapsulation
Example: Birds
subclass songbirds:
new attributes:
wings
tail
new methods:
sing
fly
subclass flightless birds:
new methods:
look in a daft manner

Object
Encapsulation
Example: Birds

Object
Encapsulation
Example: Birds
subclass tits:
new attributes:
beak = small
new methods:
clamber
subclass finches:
new attributes:
beak = big
tail = notched

Object
Encapsulation
Example: Birds

Object
Encapsulation
Example: Birds
object blue tit (e.g.):

attributes:
beak = sturdy
plumes = colored
wings = short
tail = long

Object
Encapsulation
Polymorphy
referencing of class attributes without knowing the precise

occurrence of the object addressed
example: method “fly” (songbirds)

Object
Encapsulation
Encapsulation
only interface known

internal implementation not of interest

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Process Models

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Motivation (Process Models)
code and fix: coding or correction alternating with

ad-hoc-tests (inefficient, but widely used)
job training of new colleagues
extern certification of an enterprise

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Core Processes
1 planning
2 analysis
3 design
4 programming
5 validation & verification

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Planning
requirements specification
target specification
work estimation
process model

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Analysis
requirements analysis
data analysis: conditioning / evaluation of collected data
process analysis / process model
system analysis: black box model (current / target state) as
data flow diagram:
processing and storage of data flow
state transition diagram:
temporal behavior
entity relationship diagram:
data linkage

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Design
software architecture:
structured or hierarchical arrangement of the components
description of relations between components
structured design:
structure diagrams
interface description
invocation hierarchies of the modules
Unified Modeling Language (UML)

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Validation & Verification
module tests (low level test):

test of discrete modules
integration tests (low level test):
test on interaction of several components
system tests (high level test):
test of the whole system against the specification /
requirements
acceptance tests (high level test):
test by customer

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Support Processes
quality management:
e.g.: software ergonomy
configuration management:
version control
release management
application management (user support and further
development)

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Support Processes
documentation:
software documentation tool
system documentation (further development and error
removal)
operating manual (operator / service)
user manual (user)
process documentation (description of legally relevant software
processes)

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Design Patterns - Motivation
solutions for recurring design problems

improve organization/ structure of (object oriented) source
code
experience instead of code reusal
separate the varying aspects of an application from what stays
constant
“The only constant in software development is change.”

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Design Patterns - What are Design Patterns?
Definition
A design pattern is a solution for a problem within a specific
context.
The context is a situation, in which the pattern is applied.

(e.g. a collection of objects)
The problem is the goal, which shall be reached, as well as
certain conditions. (e.g. iterate over all objects)
The solution is a common design. (e.g. encapsulate the
iteration in a separate class)

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Design Patterns - The Inventors
Design Patterns (1995), Gamma, Helm, Johnson, Vlissides

(The Gang of Four or GoF )
the idea to apply patterns goes back to Professor Christopher
Alexander, an architect
Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Design Patterns - Categories of Patterns 1

Creation Patterns
Create objects.
Factory Method
Singleton
Structural Patterns
Create more complex structures from objects / classes.
Adaptor
Fassade
Behavioral Patterns
Let objects interact.
Observer
Strategy
Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Design Patterns - Categories of Patterns 2
There are also patterns for many other areas.

Other types:
application patterns (client-server, tier model)
user interface patterns
from “real” life:
business process patterns
organisation(al) patterns

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Design Patterns - Shared Vocabulary
“I wrote a broadcast class. It remembers, which objects

belong to it, and tells them, when new data is available. An
object can register and leave whenever it wants. The
broadcast class does not have to know anything about the
listeners, they only have to implement a certain interface.”
Better:
“I use the Observer pattern.”
Makes communication easier, like technical terms.

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Design Patterns - Pattern Catalogs

names the patterns, and assigns them
to categories Name, Classification
Purpose
describes patterns and their relations Motivation
solves which problem? Applicability
Structure
a diagram explains the relations of the Participants
involved classes Interactions
Consequences
the consequences of the application Implementation
are explained ((dis)advantages) Example code
example code Known applications / us-
ages
In which programs has the pattern Related patterns
been used?
Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Design Patterns - Example: Singleton

Makes sure, that there is only one instance of a class, and provides
a global access point.

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Design Patterns - Final Comments
general solutions for recurring problems

experience reusal
only use, where it makes sense
KISS, prefer simple solutions
do not employ design patterns, because it could be useful
once (start simple, refactor if necessary)
anti patterns: look like good solutions, but they are not

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Further Reading
Design Patterns, the original

Head First Design Patterns, funny, easy to understand
The Portland Patterns Repository
http://c2.com/cgi/wiki?WelcomeVisitors
Hillside Group
http://hillside.net
Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Grouping of Process Models
phase / waterfall models:

Object Modeling Technique (OMT)
prototypical and iterative incremental process models:
spiral model
Unified Process
Extreme Programming
iterative incremental process models:
Booch
Objectory
Fusion
Catalysis
KobrA

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Phase Models
mapping of activities to phases

sequential execution of phases
changeover to next phase only after completion of previous
phase
results of a phase
are processed in the next phase
become a milestone for control of project progress (project
management)

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Milestone (Definition)
Milestones are sub-goals,

that are not defined by planned points in time,
but by content criteria.

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Phase Models - Application
Requirements have to be
describable
as stable as possible

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Phase Models - Advantages
easy integration, as
requirements are determined as completely as possible
requirements are documented
design is evolved on base of requirements
no extensive version and configuration management necessary

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Phase Models - Disadvantages
work estimation:
very difficult (deadline)
to omit sub-functions does not effect much
integration test difficult

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Waterfall Models

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Waterfall Models

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Waterfall Models

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Waterfall Models

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Waterfall Models

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Waterfall Models
controlled iterations:
anew execution of finished development activities under certain
circumstances (e.g.: removal of an error, ...)

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Waterfall Models - Application
Requirements have to be
describable
as stable as possible

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Waterfall Models - Advantages

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Waterfall Models - Disadvantages
work estimation:

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Prototypical Process Models
creation of prototypes at specific points in time during

development
analysis
design
implementation
...

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Prototypical Process Models - Application
requirements not clear

parts of requirements not clear

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Prototypical Process Models - Advantages
implementation of requested non-functional requirements
(design prototypes)
reduction of aberration risk (check of critical areas with
customer)
identification of system parts, that may be omitted in case of
time pressure (prototypes)

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Prototypical Process Models - Disadvantages
work estimation:
risks:
determination of requirements not correct
→ slowing down of development process
documentation of requirements not neatly done
→ slowing down of development process
misjudgement of a executable prototype as final version by
customer / user

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Iterative Incremental Process Models
result creation of a requirements subset in sequential order

activities basically match the phases of phase or waterfall
models, respectively
increment: all results for the requirements subset
enlargement of requirements subset and creation of new
increment
evolutionary models: expansion by risk analysis for choice of
requirements for next increment
recursive models: running of development activities for each
(sub)system

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Iterative Incremental Process Models - Application
parts of requirements not clear

parts of requirements not stable
partitioning of requirements in subsets with few dependencies
among each other has to be possible

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Iterative Incremental Process Models - Advantages
delivery deadline can be kept, if need be:

delivery of finished increments
omittance of requirements, not yet implemented in case of
time pressure
→ prioritization of requirements together with customer
integration test easy

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Iterative Incremental Process Models - Disadvantages
extensive version and configuration management

integration of different increments may be difficult

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Classification
phase waterfall prototypical iterative-inc.

models
OMT X X
Spiralmodell X X
Unified Process X X
XP X X
Booch X
Objectory X
Fusion X
Catalysis X
KobrA X
Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Summary - Application
requirements describable and stable:

phase models
waterfall models
requirements not clear:
prototypical models
iterative-incremental models
requirements not stable and apportionable:
iterative-incremental models

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Summary - Advantages / Disadvantages
advantages disadvantages
phase easy integration difficult work estimation
models easy version / config. managem. subfunctions planned
difficult integration test
waterfall easy integration difficult work estimation
models easy version / config. managem. subfunctions planned
difficult integration test
prototyp. easy integration difficult work estimation
models non-functional requirements subfunctions planned
easy version / config. managem. difficult integration test
aberration unlikely risk: determination of requirements
omittance of system parts risk: prototype as final version
it.-incr. delivery deadline kept extensive version and config. managem.
models easy integration test difficult increment integration

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Conclusion
Application of process model depends on:

project requirements
size of project
size of developer team
ability of developers to work in a team
possibilities for communication with customer
There is no process model, that can be used universally.

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Further Reading
Vorgehensmodelle kompakt - overview on process models

presented

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Extreme Programming (XP)
Kent Beck (late 1990s)

prototypical and iterative-incremental process model
application for projects with
extremely short development time
requirements not stable
agile software development
fast implementation of a executable system with a minimum
of accompanying measures, like modelling

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming

work in teams:
guide lines
collective responsibility for all development artefacts
pair programming:
changing pair compositions
→ knowledge spreading
Driver : concentration on task details
Navigator : concentration on whole project and guide lines
role change
early integration of customer:
customer is part of team
authorized to fix project goals and features
acceptance test
constant communication (developer and customer)
Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
planning phase (understanding / documentation of

requirements):
Story Cards:
prepared by customer
description of desired features
few days work
Task Cards:
created by developer team
discussion between developer and customer
for each step, needed to implement the Story
estimations for Story Cards and Task Cards:
duration
risk

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
iterative phase (realization of system):

selection of Story Cards by customer
implementation:
as simple as possible
no integration / planning of additional features
refactoring
automization
constant consultation with other developer teams and customer
delays, ... immediately to be talked over with customer
test

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
advantages:
short development cycles
precise prediction possibilities
simple and efficient implementations
disadvantages:
ideal team size: 12-14 persons
→ not applicable for major projects
disciplined working method necessary

Core Processes
Support Processes
Process Models
Design Patterns
Process Models
Consistency
Extreme Programming
Further Reading
Extreme Programming - short, descriptive introduction

Process Models
Consistency
Unified Modeling Language (UML) is a language and notation for

specification
construction
visualization
documentation
of models for software systems
The Unified Modeling Language is not a method.

Process Models
Consistency
diagram types:
use case diagram
class diagram
behavior diagram:
activity diagram
collaboration diagram
sequence diagram
state diagram
implementation diagram:
component diagram
deployment diagram

Process Models
Consistency

use case diagram:
relationship between actors and use
cases
actor:
entity outside the system
interaction with system
e.g. user, operating system, ...
use case:
activities of a system
view of actors
observable result
initiated by actor
indivisible description
Process Models
Consistency

class diagram:
base elements:
class
object
interface
component
...
relationship elements:
inheritance
association
aggregation
composition
dependency relation
Process Models
Consistency
activity diagram / flow chart:

describes workflow possibilities of a system
special form of state diagram
activity: single step in a workflow
concurrency
applicable as object flow diagram

Process Models
Consistency
collaboration diagram / interaction diagram:
interactions between objects

narrow situation
stress on relationships
other point of view than sequence
diagram

Process Models
Consistency
sequence diagram / interaction diagram:

message exchange between objects
temporally limited situation
stress on temporal progress
other point of view than collaboration
diagram

Process Models
Consistency
state diagram / state transition diagram:

sequence of states, a object can take
state changes
hypothetic machine (finite machine)

Process Models
Consistency
component diagram:
relationship of components
among each other
component:
software
own identity
defined interfaces

Process Models
Consistency
deployment diagram:
configuration of nodes (processes,
computer)
→ assignment of components and
objects to nodes
communication relations at nodes

Process Models
Consistency
Further Reading
Die UML-Kurzreferenz für die Praxis - overview on most

important diagram types, each with definition, description,
notation and example
Consistency and Programming Style
Names
Expressions and Statements
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
make complexity manageable

consistent source code is easier to understand
look of the source code is important, too
pedantic? consistent, professional!
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Programming Style
The purpose of a specific programming style is to make the code

easier to read for oneself and others.
simplicity (keep programs short and managable)
clearness (intelligible especially for human beings)
generality (work correctly in different situations)
Good style is important, if you want to program well.

Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Bad Style

Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Good Style
Well written programs are better than badly written ones, because:
easier to read
more intelligible
contain less errors
easier to debug
easier to modify
Requires discipline.
Compilers have no problems with badly written code, but humans
do...

Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Good Style
The principles of a programming style are based upon common
sense and programming experience.
Code should be clear and simple:
straightforward logic
natural expressions
conventional language usage (stick to the proven)
meaningful names
neat formatting / layout
useful comments
Avoid clever tricks and unusual constructs!

Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Consistency
Consistency makes the code easier to read for other

programmers.
important within a team: common style (guide)

Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Names
A name
describes a certain object (or function)
conveys information about its purpose
should be informative, short, catchy and pronounceable
the bigger the scope, the more information the name should
convey
Descriptive names for global variables, and short names for local
variables.
Be consistent: similar things should have similar names. Not Q,

Queue and queue.
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Names - Variables
Local variables:
should be short
i, j for loop variables
p, q for pointers (nodep)
s, t for strings
n: amount, nPoints (numberOfPoints is exaggerated)

Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Names - Variables
Clearness is often achieved by shortness.
1 for ( theElementIndex = 0;
2 theElementIndex < numberOfElements ;
3 theElementIndex ++)
4 elementArray [ theElementIndex ] =
theElementIndex ;
Better:
1 for ( i = 0; i < nElems ; i ++)
2 elem [ i ] = i ;

Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Names - Variables
Global variables:
often begin with capital letters or ’ ’
usually have longer (self-explanatory) names
(PointsOfInterest, RemoteAccessPoints)
Constants:
often with capital letters (MAX SIZE)

Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Names - Functions
Use names which express activities for functions: verbs, maybe

followed by a noun.
1 now = date . getTime () ;
2 putchar ( ’\ n ’) ;
Return values should be easy to interpret:
1 if ( checkoctal ( c ) )
better:
1 if ( isoctal ( c ) )

Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Names - Naming Conventions
Spelling of the names purely is a matter of taste:

1 nPending
2 numPending
3 num_pending
Special rules are less important than the consistent adherence of a

style.

Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Write the clearest code that does the job.

Format source code in such a way that it is easily readable.
Trivial in a sense, but important.

Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Expressions and Statements - Indentation
Indent in order to clarify structures:

1 for ( n ++; n <100; field [ n ++]= ’ \0 ’) ;
2 * i = ’ \0 ’; return ( ’\ n ’) ;
Reformatting ameliorates the situation a bit:
1 for ( n ++; n < 100; field [ n ++] = ’ \0 ’)
2 ;
3 * i = ’ \0 ’;
4 return ( ’\ n ’) ;
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Expressions and Statements - Indentation
Conventional form, is easier to understand:

1 for ( n ++; n < 100; n ++)
2 field [ n ] = ’ \0 ’;
3 * i = ’ \0 ’;
4 return ( ’\ n ’) ;
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Expressions and Statements - Expressions
Expressions should be written in a natural form:

as you would pronounce them
negations are difficult to understand
1 if (!( n < min ) && !( n > max ) )
Better formulate comparisons positive:
1 if (( n >= min ) && ( n <= max ) )
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Expressions and Statements - Parentheses
Place parentheses to avoid ambiguities:

shows the grouping
makes intention clear, even if not necessary
1 leapYear = y % 4 == 0 && y % 100 != 0
2 || y % 400 == 0;
Better with parentheses:
1 leapYear = (( y % 4 == 0) && ( y % 100 != 0) )
2 || ( y % 400 == 0) ;
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Expressions and Statements - Complex Expressions
Complex expressions should be subdivided:

1 * x += (* xp = (2 * k < ( n - m )
2 ? c [ k + 1] : d [k - -]) ) ;
easier to understand:
1 if (2 * k < n - m )
2 * xp = c [ k + 1];
3 else
4 * xp = d [k - -];
5 * x += * xp ;
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Expressions and Statements - Express yourself clearly
Always try to write clear code instead of the shortest possible:

1 child = (! LC &&! RC ) ?0:(! LC ? RC : LC ) ;
1 if ( LC == 0 && RC == 0)
2 child = 0;
3 else if ( LC == 0)
4 child = RC ;
5 else
6 child = LC ;
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Expressions and Statements - Express yourself clearly
Always try to write clear code instead of (would-be) clever code:

1 subkey =
2 subkey >> ( bitoff - (( bitoff >> 3) << 3) ) ;
1 subkey = subkey >> ( bitoff & 0 x7 ) ;
or:
1 subkey > >= bitoff & 0 x7 ;
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Expressions and Statements - Side Effects
Avoid code with side effects:

1 i = 3;
2 array [ i ++] = i ;
Which array element is set to which value?
Side effects sometimes are defined sometimes they are not. If
unsure: rewrite the code.
1 i = 3;
2 array [ i ] = i ;
3 i ++;
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Consistency and Idioms
Consistency leads to better programs.

Not:
iterate loops once forwards once backwards
copy strings once with strcpy, another time with loops
Similar ”calculations” should always be computed in the same way.
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Consistency and Idioms - Consistency when Indenting and

Placing Parentheses
Indentations reveal the structure.
Opening parentheses on the same line as the if, for, ...?

The eventually used style is less important than its consistent
adherence.
When changing foreign code, stick to the style used.
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Consistency and Idioms - Consistency when Indenting
1 if ( month == FEB )
2 {
3 if ( year %4 == 0)
4 if ( day > 29)
5 legal = false ;
6 else
7 if ( day > 28)
8 legal = false ;
9 }
The indentations here are misleading! (else)
(Hint: Also enclose single lines with curly brackets.)
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Consistency and Idioms - Idioms

One of the most common idioms is the form of a loop.
Unusual:
1 i = 0;
2 while ( i <= n - 1)
3 array [ i ++] = 1.0;
or:
1 for ( i = 0; i < n ; )
2 array [ i ++] = 1.0;
or like this:
1 for ( i = n ; --i >= 0; )
2 array [ i ] = 1.0;
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Consistency and Idioms - Idioms
Common form:
1 for ( int i = 0; i < n ; i ++)
2 array [ i ] = 1.0;
n elements visited
in ascending order
whole control of the loop is within the for-expression
++-operator is used to increment
Always use well known idioms.
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Consistency and Idioms - Loops
Standard loop for iteration over a list in C:

1 for ( p = list ; p != NULL ; p = p - > next )
2 ...
Infinite loops:
1 for (;;)
2 ...
3 while ( true )
4 ...
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Consistency and Idioms - Multiple Decisions

Else-clauses should be vertically aligned instead of on the level of
the respective if. Stresses, that tests are executed in order.
1 if ( Condition1 )
2 Statement1
3 else if ( Condition2 )
4 Statement2
5 ...
6 else
7 Default Statement
As soon as a condition is fulfilled the respective statement / code
is executed, and program flow continues after the last else-branch.
Avoids code which moves to the right hand side. (Deep nesting
usually is a sign for bad code.)
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Function Macros
avoid them
#define simply is a textual substitution
changes the lexical structure of a program in the background
use inline functions in C++
A parameter, which appears more than once in the definition of the
macro will be evaluated more than once.
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Function Macros
Unintended multiple evaluation:

1 # define isupper ( c ) (( c ) >= ’A ’ && ( c ) <= ’Z ’)
2
3 while ( isupper ( c = getchar () ) )
Will be expanded to:
1 while ((( c = getchar () ) >= ’A ’ &&
2 ( c = getchar () ) <= ’Z ’) )
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Magic Numbers
Magic numbers are the constants, array sizes, cursor positions,

conversion factor and other literal numerical values, which
appear in a program.
Name magic numbers!
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Magic Numbers - Negative Example

1 fac = lim / 20; // set scaling factor
2 if ( fac < 1)
3 fac = 1;
4
5 // generate histogram
6 for ( i = 0 , col = 0; i < 27; i ++ , j ++) {
7 col += 3;
8 k = 21 - ( let [ i ] / fac ) ;
9 star = ( let [ i ] == 0 ) ? ’ ’ : ’* ’;
10 for ( j = k ; j < 22; j ++)
11 draw (j , col , star ) ;
12 }
13
14 draw (23 , 2 , ’ ’) ; // draw x-axis
15 for ( i = ’A ’; i <= ’Z ’; i ++)
16 printf ( " % c " , i ) ;
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Magic Numbers - Better (1/2)

1 enum {
2 MINROW = 1 , // upper row
3 MINCOL = 1 , // left column
4 MAXROW = 24 , // lower row
5 MAXCOL = 80 , // right column
6 LABELROW = 1 , // label position
7 NLET = 26 , // alphabet size
8 HEIGHT = MAXROW ? 4, // bar height
9 WIDTH = ( MAXCOL ? 1) / NLET // bar width
10 };
11
12 // set scaling factor
13 fac = ( lim + HEIGHT - 1) / HEIGHT ;
14 if ( fac < 1)
15 fac = 1;
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Magic Numbers - Better (2/2)
1 // generate histogram
2 for ( i = 0 , i <= NLET ; i ++) {
3 if ( let [ i ] == 0)
4 continue ;
5 for ( j = HEIGHT - let [ i ] / fac ; j < HEIGHT ; j ++)
6 draw ( j + 1 + LABELROW , ( i + 1) * WIDTH , ’* ’
);
7 }
8 // draw x-axis
9 draw ( MAXROW - 1 , MINCOL + 1 , ’ ’) ;
10 for ( i = ’A ’; i <= ’Z ’; i ++)
11 printf ( " % c " , i ) ;
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Magic Numbers
Define magic numbers as constants.

Do not use #define (macro!) in C:
1 enum { MAXROW = 24 };
In C++:
1 const int MAXROW = 24;
In Java:
1 static final int MAXROW = 24;
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Comments
Comments should help to understand a program. They should

briefly point out important details or give an overview on program
flow.
Comments should contain additional information, which can not

directly be deduced from the code. Or they could collect
distributed information at one place.
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Comments
Comments should not repeat the obvious:

1 // Default behavior
2 default :
3 break ;
4
5 // return SUCCESS
6 return SUCCESS ;
7
8 zerocount ++; // increment zero - entry - counter
9
10 // initialise " total " with " number_received "
11 node - > total = node - > number_received ;
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Comments - Functions and Global Data
Functions and global data should be commented.

global variables are often distributed in big spans over the
program code: memory hook
a comment before a function can often save you from reading
its code
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Comments
Bad code should not be commented: rewrite it! When there is

more comments than code, then the code probably needs a
rewrite.
Do not contradict the code. When changing code it is easy to
forget to change the comments, too. Inconsistency confuses.
Create clearness, not confusion (do not raise more questions).
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Comments
Comments should help to understand parts of a program,

which cannot be understood by simply browsing the code.
Write code, which is easy to understand. Then less comments
have to be written.
Good code needs less comments than bad code.
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Summary 1/2
Programming style
descriptive names
clearness in expressions
straightforward control flows
readability of code and comments
consistent adherence to conventions and idioms
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Summary 2/2
Is it worth the effort?

Well written code
is easier to read and understand
usually contains less errors
is often shorter than careless crafted code
Careless code is bad code.
Good style should be a habit.
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Miscellaneous
Source code should be in English
Functions should be short (short is smart)
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Further Reading
The Practice of Programming (Brian W. Kernighan, Rob

Pike)
Names
Process Models
Function Macros
Magic Numbers
Consistency
Comments
Summary
Style Guides
Orthogonality
Automation
Refactoring
Style Guides
Style Guides
Orthogonality
Automation
Refactoring
Motivation
avoid spaghetti code, ...

avoid errors
easier understanding of code by colleagues
debugging easier, as old code more understandable
Style Guides
Orthogonality
Automation
Refactoring
Content
commenting of source code (key words)

naming
formatting
terms
order of attributes in class declarations
access rights and methods of classes
Style Guides
Orthogonality
Automation
Refactoring
Naming
consistent naming (variables, constants, ...)

e.g. hungarian notation:
Charles Simonyi
marking of variables and functions by optional prefix,
declaration of data type and identifier
variable name for identification
prefix and declaration of data type usually in one or two
lowercase letters:
pointer flag character function word long byte ...
p f ch fn w l b ...
identifier begins with capital letter
identifier combined from words beginning with capital letters
Style Guides
Orthogonality
Automation
Refactoring
Formatting
indent
associated terms
parenthesizing for blocks
controlled data flow:
empty blocks
blocks with only one line
Style Guides
Orthogonality
Automation
Refactoring
Terms
avoidance of shift operators replacing arithmetic operations

parenthesizing
constants instead of figure literals
Style Guides
Orthogonality
Automation
Refactoring
Conclusion
It is important, that
1 there is a style guide
2 the whole team keeps with the style guide
3 the style guide is comprehensible
4 the style guide covers as many aspects as possible
5 exceptions are possible, but do not become the rule
Style Guides
Orthogonality
Automation
Refactoring
Examples
Some ”official” style guides:

http://java.sun.com/docs/codeconv/html/
CodeConvTOC.doc.html
http://www.perl.com/doc/manual/html/pod/perlstyle.html
A style guide generator for C, C++ and Java:
http://www.rosvall.ie/CSG/
Style Guides
Orthogonality
Automation
Refactoring
Source Code Formatters
Source code formatters adapt source code to own preferences:

http://jalopy.sourceforge.net (Java)
http://perltidy.sourceforge.net (Perl)
bcpp (http://dickey.his.com/bcpp/bcpp.html) (C++)
http://www.faqs.org/docs/Linux-HOWTO/C-C++Beautifier-
HOWTO.html
Artistic Style (http://astyle.sourceforge.net) (C, C++, C#,
and Java)
Style Guides
DRY Principle
Reasons for Repetitions
Orthogonality
Summary
Automation
Data Formats
Refactoring
DRY Principle
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
The Evil of Repetition
As a programmer you collect, organize, maintain and use

knowledge.
Knowledge is not stable, it changes rapidly.
requirements (of the client) can change
a chosen algorithm may not work (as expected)
laws change
This instability leads to the fact, that knowledge within a system
has to be reorganized and reformulated again and again.
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
DRY Principle
If the same piece of knowledge appears at two

or more places, you have to remember to
change all of them if one representation is
modified. Otherwise ugly discrepancies will
arise.
The question is not whether you forget the other occurrencies but
when.
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
How Do Repetitions Come Into Being?
Forced Repetition. You seem to have no choice.

Circumstances seem to require the repetition.
Unintended Repetition. Accidentally.
Repetition due to impatience. Lazyness. Repeat, since it
seems to be easier this way.
Repetition due to many developers. Several developers
repeat the same piece of information.
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
Forced Repetition - Different Representations of the Same

Information
Often the same information is needed in several forms /

representations.
Client-Server applications written in different programming
languages, which have to use the same structures.
A class which represents the scheme of a database.
Creation of slides, which contain source code, which should be
tested before inclusion.
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
Forced Repetition - Different Representations of the Same

Information
Possible solutions:
filters or source code generators, which refer to the same meta
data
generate source code files, which declare structures, for several
languages
generate class declarations from database descriptions
insert source code via the include directive
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
Forced Repetition - Comments
Concrete knowledge belongs into the source code. Comments are

meant for abstract explanations.
Otherwise knowledge is repeated, and with every change the source
code as well as the respective comments have to be changed.
1 // valid for Germany and Switzerland
2 if (( country == " Austria " ) ||
3 ( country == " Switzerland " ) ||
4 ( country == " France " ) )
5 {}
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
Forced Repetition - Comments
Better:
1 // check whether we have a valid country
2 if (( country == " Austria " ) ||
3 ( country == " Switzerland " ) ||
4 ( country == " France " ) )
5 {}
Wrong comments are worse than none at all.
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
Forced Repetition - Documentation within the Source Code
You write code, and then the documentation.

You change the code, and have to change the documentation
as well.
You change the code again, ...
Extract the documentation from the code! (Doxygen, a self-made
script)
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
Forced Repetition - Language Problems

In Java the class declaration and definition are the same.
In C++ there are header files (declarations) and the actual
implementation of the code (implementation of the declarations).
1 // stack . h
2 class IntStack
3 {
4 int pop () ;
5 };
1 // stack . cpp
2 int IntStack :: pop ()
3 {
4 }
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
Unintended Repetition
Mistakes in design:
1 class Van 1 class Tour
2 { 2 {
3 string model ; 3 string from ;
4 string licencePlate ; 4 string to ;
5 string driver ; 5 string driver ;
6 }; 6 };
When the van is sent on tour, the driver appears twice.
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
1 class Line {
2 public :
3 Point start ;
4 Point end ;
5 double length ;
6 };
If either ’start’ or ’end’ is modified, length has to be recalculated,
too.
(Side note: Variables should never be public. Getter and setter
methods should be used instead.)
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
Calculation instead of storing:
1 class Line {
2 public :
3 Point start ;
4 Point end ;
5 double length () {
6 return start . distanceTo ( end ) ;
7 }
8 };
Access:
1 double len = line . length ; // bad
2 double len = line . length () ; // good
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
If the calculation is time consuming you can cache the result.
1 class Line {
2 public :
3 Point getEnd () ;
4 void setEnd ( Point p ) {
5 end = p ;
6 upToDate = false ;
7 }
8 double length () {
9 if (! upToDate ) {
10 length = start . distanceTo ( end ) ;
11 upToDate = true ;
12 }
13 return length ;
14 }
15 };
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
Unintended Repetition of Code

Code that appears more than once should be sourced out to one
location (e.g. a function):
1 _cldb - > getSig ( get_c_string ( car ( file ) ) ) ;
2 _cldb - > getCoefs ( get_c_string ( car ( file ) ) ) ;
1 const EST_String
2 fileName ( get_c_string ( car ( file ) ) ) ;
3
4 _cldb - > getSig ( fileName ) ;

5 _cldb - > getCoefs ( fileName ) ;
reduces error sources, since there is less code

can avoid calculating the same result again and again
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
Repetition due to Impatience
If in need of a function, which resembles an already existing one,

one is often tempted to copy the original and slightly modify it.
It is better to make the original function more flexibler to make it
usable for both purposes.
Or you could call the original function from the new one.
Shortcuts take longer.
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
Repetition due to many Developers
These are difficult to detect and avoid.

Everybody programs his own auxiliary functions. Many of them
exist several times.
Active and frequent communication is important.
You could install a discussion forum (or a wiki).

Auxiliary functions should be stored at a central place.
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
Repetition due to many Developers
Reuse has to be made easy.
E.g. store information in a project wiki.
If it is not easy to do, people will not do it.
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
Backups
Backups do not count as redundant repetition of information.
Create backups often.
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
DRY Principle
Each piece of knowledge has to have one clear-cut, authoritative

representation within a system.
DRY - Don’t Repeat Yourself!
Is one of the most important ”tools” of a (pragmatic) programmer.
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
Summary - DRY Principle
Don’t Repeat Yourself

avoid repetition due to impatience and ignorance
let different representations of data be created
reuse code and data
make reuse easy (automation)
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
Data Formats
Store knowledge as plain text if possible.

Plain text consists of printable characters and can be read and
directly understood by humans.
Field42=0x23
consists of printable changes but is meaningless.
Better, since understandable:
DrawingType=UMLActivityDrawing
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
Data Formats
Plain text is often more abstract than binary code.

window.displayFrame=FALSE
vs. binary:
00101010
Problem of most binary formats:
Context necessary for the understanding of the data is separated /
isolated from the data. Without the application logic it is
meaningless.
With plain text you can achieve a self describing data stream.
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
Data Formats
Advantages of plain text:

portable (caution: line separators)
easy to read
accessible for each kind of tool (not only for the generating
one)
insurance against becoming obsolete
simplifies testing since input data can easily be generated
Example: XML
Style Guides
DRY Principle
Orthogonality
Summary
Automation
Data Formats
Refactoring
Data Formats
Disadvantages of plain text:

file sizes (but: zip and co)
loading (parsing) can take longer
Store as plain text if possible.
Style Guides Orthogonality
DRY Principle / Reuse Increased Productivity
Orthogonality Reduced Risk
Automation Large Projects
Refactoring Summary
Orthogonality
Refactoring Summary
What is Orthogonality?
Orthogonality is a term from geometry.
2 straight lines are orthogonal if they

intersect in a right angle
viewed as vectors they are independent of
each other
In computer science:
independency
decoupling
Two or more things are orthogonal, if changing one of them does

not affect the others.
Refactoring Summary
Orthogonality
Orthogonality is a key concept, if you want to create systems that

are easy
to design
to build
to test
and to extend
Refactoring Summary
What is Orthogonality?
In a well designed system for example the database is orthogonal

to the user interface.
You can change one without affecting the other.
Refactoring Summary
Orthogonality
Non-orthogonal systems are difficult to change by nature.

If the parts of a system are dependent of each other a locally
limited change is not possible.
Remove interdependencies between independent things.
Refactoring Summary
Orthogonality
Components should be self-contained:

Independent, and with a unique, well defined purpose
(loose coupling, strong cohesion)
If components are isolated from each other, you can change one,
without having to worry about the rest.
Refactoring Summary
Isolated Function
1 float calcFunnyNumber ( float x , float offset , int n )

2 {
3 float temp = 0.0;
4
5 for ( int i = 0; i < n ; i ++)
6 {
7 temp += temp * x ;
8 }
9
10 return temp + offset ;
11 }
strong cohesion: fulfills a well defined purpose

loose coupling: uses only passed parameters and local variables
Refactoring Summary
Increased Productivity
Changes are locally limited:

reduces time needed for development and testing
it is easier to write small self-contained components
existing source code rarely has to be adapted
Supports reuse:
if components have specific, well defined responsibilities, they
can be combined in various (unforeseen) ways (loose coupling)
Refactoring Summary
Increased Productivity
Subtle increase in productivity:

Two components with different functionalities (M, N) can
accomplish MxN new things. With non-orthogonality there
are overlaps, and accordingly less combination possibilities.
Refactoring Summary
Reduced Risk
Orthogonal approaches reduce the inherent risks of all software

development.
Problematic parts of source code will be isolated:
if there are problems in a module, it is less probable that the
symptoms expand to the whole system
The system is more robust:
fixes at one place have positive effects on other parts of the
system
Refactoring Summary
Reduced Risk
Probability of better testing increases:

it is easier to design and run tests for single components
Reduced obligation to a specific producer:
interfaces to third party components are reduced to a lesser
part of the source code
Refactoring Summary
Project Teams
In efficient teams there are only few overlaps, since everybody has
special responsibilities.
Responsibilities require no meeting with the whole team, since not
everybody is affected.
Refactoring Summary
Design
Systems should be composed of a set of cooperating modules.
E.g. subdivision in tiers (every tier only accesses the tier directly
below it)
Refactoring Summary
Implementation
Keep source code decoupled:

write shy code (encapsulation)
Avoid global data:
access to this data is distributed over the whole source code
necessary context should be passed directly to the modules /
functions
Avoid similar functions:
repeated source code is a symptom for structural problems
e.g. use the strategy or template pattern
Refactoring Summary
Testing
An orthogonal system is easier to test. Many tests can take place

on the level of single modules, since interactions between
components are ordered and limited.
Good, since module tests are easier to specify and run than
integration tests.
Refactoring Summary
Summary - Orthogonality
do not distribute inseparable knowledge over multiple system

components
remove interdependencies between independent things
(modules, classes, components, tiers)
avoid global data
increased productivity, since changes are locally limited (loose
coupling)
supports reuse, new combination possibilities (Unix tools)
Refactoring Summary
Further Reading
The Pragmatic Programmer. From Journeyman to

Master (Andrew Hunt, David Thomas)
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Automation
“Civilization advances by extending the number of important

operations which we can perform without thinking about them.”
(Alfred North Whitehead)
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Automation
The instructions manual for starting a Ford T was more than 2

pages long...
error-prone procedure
annoying
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Examples for Automation when Programming
build process
releasing new program versions
paperwork for source code reviews
renaming 100 files
As much as possible has to be automated!
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Consistency and Reproducibility
Automation is important to ensure consistency and

reproducibility in a project.
Manual procedures leave consistency to chance whereby
reproducibility is not guaranteed.
Instruction manuals often leave room for interpretations.
(Starting the Ford T!)
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Automatic
A shell-script or batch-file executes the same instructions in the

same order over and over again.
Avoid manual operations!
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Compile projects
Compilation of a project is a routine job. It should be

reliable
and repeatable.
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Make
changing one source file only leads to the recompilation of

affected files
is a central place for configuration options for all incidental
tasks (clean, doc, install, test, create)
additional work in the beginning, but it pays off in the long run
not only useful for source code
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Structure of Makefiles
Rules: Describe how a target is created from one or more sources.

1 Target : Source1 Source2 ... SourceN
2 <tab > Command1
3 <tab > Command2
Invocation of make:
1 make [ - f Makefile ] [ foobar ]
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
1 foobar : foo . c bar . c
2 gcc foo . c bar . c -o foobar
This creates foobar completely from scratch, even if only one c-file
has been changed.
Better:
1 foobar : foo . o bar . o
2 gcc foo . o bar . o -o foobar
3
4 foo . o : foo . c
5 gcc foo . c -c
6
7 bar . o : bar . c
8 gcc bar . c -c
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Phony targets:
1 clean :
2 rm -f *. o
If there are several targets by default the first one is chosen. This
is often called ’all’, and its dependency is the main target.
1 all : foobar
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Implicit rules:
1 . cpp . o :
2 $ ( CXX ) $ ( DBG_FLAGS ) -o $@ -c $ ( CXXFLAGS ) $ <
is a rule that describes how .o-files can be created from .cpp-files.

Automatic variables:
$@ represents the file name of the target, which triggered the
execution of this rule.
$< represents the name of the first dependency.
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Generating Source Code
In order to avoid repetitions source code and other files can be

derived from common sources.
The dependency mechanism of make can simplify this process.
1 . SUFFIXES : . java . class . xml
2
3 . xml . java :
4 convert . pl $ < > $@
5
6 . java . class :
7 $ ( JAVA ) $ ( JAVAC_FLAGS ) $ <
make test.class searches a file called ’test.xml’, creates (by

means of a Perl-script) a Java-file and compiles the latter.
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Exercise: make
A simple Makefile:
2 gcc foo . o bar . o -o foobar
3
4 foo . o : foo . c
5 gcc foo . c -c
6
7 bar . o : bar . c
8 gcc bar . c -c
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Exercise: make
A better Makefile:
1 . PHONY : clean
2 . SUFFIXES : . cpp . o
3
4 CXX := g ++
5 DBG_FLAGS := -g
6 CXXFLAGS := $ ( DBG_FLAGS ) -I .
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Exercise: make
7 all : foobar
8
9 clean :
10 rm -f *. o
11
13 gcc foo . o bar . o -o \ $@
14
15 . cpp . o :
16 $ ( CXX ) $ ( DBG_FLAGS ) -o $@ -c $ ( CXXFLAGS ) $ <
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Build Process
The build process starts with an empty directory, and builds the
project from scratch. It creates what shall be delivered at the end
(CD-ROM-Master, self extracting archive, etc.).
1 Checking the source code out from the version control system.
2 Building the project from scratch (e.g. by employing make).
Each run of the build process gets its own version number.
3 Creation of a complete version which can be distributed.
4 Executing test runs.
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Build Process
In many projects this kind of build process is executed each night

automatically.
In the process often complete tests are conducted. This way you
can see the next morning whether changes have introduced errors.
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Creating Web Pages
The build process also can:

create documentation
update (internal) web pages
Everything should be
created from information contained in the version control
system
and be published without human interference.
Here we have the DRY principle again: Information exists in just

one form. A web page is just (one example for) a view onto it.
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Approval Procedures
In some projects certain administration procedures have to be

obeyed:
reviews of source code and designs have to planned and
conducted
approvals have to be issued
Paperwork can be simplified through automation.
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Approval Procedures
1 // Status: needs_review
A script could search the source code hierarchy for such files and:
publish a list of these files on a web page
send an email to the responsible persons
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
cron
Executes tasks at predefined points in time.

1 # MIN HOUR DAY MONTH DAYOFWEEK COMMAND
2 #-----------------------------------------------
3 5 0 * * * / projects / Manhattan / bin / nightly
4 15 3 * * 1 -5 / usr / local / bin / backup
5 0 0 1 * * / home / accounting / expense_reports
1 crontab crontab . txt

2 crontab -e
3 crontab -r
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
find
find helps searching files

1 find . - name " *. tex "
2 find / usr / local - perm -400
3 find / etc - type d
4 find . - type f - empty
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
grep
grep helps finding files which contain certain patterns

1 grep " Subject : " ~/ mbox - spam
2 grep -v DONT_SHOW
3 grep -l PATTERN *
4 cat participants . txt | grep Tom
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Exercise: cron
create a crontab.txt file

start cron with your crontab.txt file
check the currently installed cron table
stop cron
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Exercise: find
find in the current directory all files with the suffix cpp
find in /usr/local all files which are writeable for the user
find all directories in and below /tmp
find all empty files in and below the home directory
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Exercise: grep
search ∼/mbox-spam for lines which contain ”Sender:”

search all lines which do not contain ”passwd”
display the name of all files containing ”work”
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Bash
Loops:
1 for i in ‘ find . - name " *. tex " ‘; do
2 echo $i ;
3 done
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Bash
Renaming files:
1 for i in ‘ find . - name " *. tex " ‘; do
2 mv $i ;
3 done
Parameter expansion:
1 $ { parameter #word}
2 $ { parameter ##word}
3 $ { parameter % word }
4 $ { parameter %% word }
5 $ { parameter / pattern / string }
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
cms.sh
1 if [ -f ~/ mbox - spam ]; then

2 grep " Subject : " ~/ mbox - spam ;
3 fi
1 if [ -f ~/ mbox - spam ]; then

2 grep " Subject : " ~/ mbox - spam | grep -v SPAM ;
3 fi
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
f.sh
1 #!/bin/bash
2
3 if [ $ # -eq 0 ]
4 then
5 echo " usage : $ {0} < SEARCH_PATTERN > <
FILES_TO_SEARCH > "
6 echo " e . g .: $ {0} printf \ " *. cc \ " "
7 exit 1
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
f.sh
8 elif [ $ # -eq 1 ]
9 then
10 SEARCH_PATTERN = $ {1}
11 FILES_TO_SEARCH = " * "
12 else
13 SEARCH_PATTERN = $ {1}
14 FILES_TO_SEARCH = $ {2}
15 fi
16
17 find . - name " $ { FILES_TO_SEARCH } " | xargs grep " $ {
SEARCH_PATTERN } "
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
sameRightsForGroup.sh
1 #!/bin/bash
2
3 echo " Giving the group the same rights as the owner
... "
4
5 for i in ‘ find . - perm -400 ‘; do
6 chmod g + r $i
7 done
9 chmod g + w $i
10 done
12 chmod g + x $i
13 done
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
replace.pl
1 #!/usr/bin/perl -w
2
3 if (! defined ( $ARGV [0]) && ! defined ( $ARGV [1]) && !
defined ( $ARGV [2]) )
4 {
5 print ( " usage : replace . pl < search > < replace > <
fileName >\ n \ n " ) ;
6 print ( " where < search > is the string to search
for \ n " ) ;
7 print ( " and < replace > the string to insert
instead .\ n " ) ;
8 exit (1) ;
9 }
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
replace.pl
10 $searchString = $ARGV [0];

11 $replaceString = $ARGV [1];
12 $fileName = $ARGV [2];
13
14 $tmpFile = $fileName . " . " . getpgrp (0) . " . tmp " ;
15
16 open ( IN , " $fileName " )
17 || die " Cannot open $fileName for reading : $ ! " ;
18
19 open ( OUT , " > $tmpFile " )
20 || die " Cannot open $tmpFile for writing : $ ! " ;
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
replace.pl
22 while ( < IN >)

23 {
24 $line = $_ ;
25
26 if (/ $searchString /)
27 {
28 $line =~ s / $searchString / $replaceString / g ;
29 }
30
31 print ( OUT $line ) ;
32 }
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
replace.pl
34 close ( IN ) ;
35 close ( OUT ) ;
36
37 unlink ( $fileName ) ;
38 rename ( $tmpFile , $fileName ) ;
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Spaces at the End of Lines
1 #!/bin/bash
2
3 for i in ‘ find . - name " *. tex " | xargs grep -l ’ \+ $
’ ‘; do
4 echo $i ;
5 replace . pl ’ +$ ’ ’’ $i ;
6 done
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Avoid Repetitions
If you realize that you repeat a task over and over again
(cumbersome), think about how you could automate it.
frees the programmer from routine work
Automation
Style Guides
Make
Build Process
Orthogonality
Useful Programs
Automation
Scripts
Refactoring
Summary
Summary
avoid manual tasks

use script languages (Perl, Python, Tcl, *sh, ...)
PCs love to do stupid things (and are better at it than
humans)
write source code that creates source code
things that are easy to do are more likely to be done
Style Guides Broken Windows
DRY Principle / Reuse Programming with Chance
Orthogonality Refactoring
Automation Examples
Refactoring Summary
Entropy
Entropy is a term from physics, which describes the measure of

disorder in a system.
Unfortunately the laws of thermodynamics say that entropy strives
to reach a maximum within the universe.
If chaos within software increases programmers say: ”The software
decays.”
Automation Examples
Refactoring Summary
Broken Windows
Some projects look like this, others like that:
Automation Examples
Refactoring Summary
Broken Windows
Decay begins with a broken window...
... and gets worse and worse. You feel more and more
uncomfortable and sometime there is no more interest in a
”renovation”.
Thus:
Do not accept broken windows.
Automation Examples
Refactoring Summary
Broken Windows
An experiment in New York began with an intact car and ended

like this:
Automation Examples
Refactoring Summary
Broken Windows
Do not leave bad source code as it is, but fix it a soon as you
detect it.
Otherwise the following attitude could arise:
”The rest of the source code already is rubbish. I will simply
continue like this.”
In a project with cleanly written source code you will take more
care when programming. Nobody wants to be the first to do
damage.
Automation Examples
Refactoring Summary
Broken Windows
In case of lack of time:

output a message
comment source code
1 // FIXME : this does not work
2 // XXX : nonsense
3 // TODO : make it work
Automation Examples
Refactoring Summary
Summary
software decays
fix errors when you detect them
no “I will fix that later”
code which looks chaotic, often is
Automation Examples
Refactoring Summary
Programming with Chance
1 paint ( g ) ;
2 invalidate () ;
3 validate () ;
4 revalidate () ;
5 repaint () ;
6 paintImmediately ( r ) ;
Despair?
It seems to work. But why?
Automation Examples
Refactoring Summary
Chance in Testing
It is easy to assume, that X inevitably leads to Y.
Do not guess, prove.
Do not program / test with chance.
Automation Examples
Refactoring Summary
Deliberate Programming
Goal: produce source code with less effort and detect and remove
errors as soon as possible.
Always be aware of what you do.
Do not program blindfolded.
understand the program
understand technology
Follow a plan (i.e. think first).
Automation Examples
Refactoring Summary
Deliberate Programming
Only rely on reliable things. No coincidences or assumptions.

Document assumptions.
Not only test source code, but also assumptions. Do not
guess, but try out.
Automation Examples
Refactoring Summary
Programming with Chance
”Never change a running system”?

Maybe it does not really work, but just looks like it does.
Accidental boundary case.
Undocumentend behavior could change in the next library
version.
Additional superfluous calls, make the program slower.
Additional calls increase the risk to add additional errors.
Only rely on documented behavior.
Automation Examples
Refactoring Summary
Summary
“It does work, better not touch anything...” (Anonymous

Programmer)
Alarming. Most certainly this programmer does not understand the
system. (Otherwise he would know, how to change it.)
never program with chance
always understand what you do
only rely on the reliable
if necessary replace unintelligible source code (refactor)
Automation Examples
Refactoring Summary
Refactoring
Building a house is a common metaphor for software development:
an architect draws a plan

the foundation is excavated, floors are built, electricity, water
supply, completion of the interior
tenants move in, and call the janitor if problems arise
But software development does not work this way!
Automation Examples
Refactoring Summary
Refactoring
A more appropriate term is gardening:
with an initial plan, and under

consideration of the environmental
conditions different things are planted in
the garden
some plants blossom, others do not
plants get replanted
you weed and you manure
You watch and intervene if required.
Automation Examples
Refactoring Summary
Refactoring - Definition
Source code is not static. It has to develop.
Rewriting, revising and redesigning source code is commonly

known as refactoring.
During this process the functionality usually is not changed.
Automation Examples
Refactoring Summary
How to refactor?
Refactoring is a task which has to be executed slowly, deliberately

and accurately.
Do not refactor and implement new functionality at the same
time.
Write test code and run it before and after the change.
(Changes can introduce new errors).
Only make small changes at each step.
Refactor soon and often.
Automation Examples
Refactoring Summary
Simple Extension
If you want to extend a program with a new feature and this is not
easily feasible, then you should first change the code, in order to
make it easy to extend. Only then should you integrate the new
feature.
Automation Examples
Refactoring Summary
Procedure
Small steps:
confidence in the code grows
less stress
Tool supported refactoring:

Smalltalk-Refactoring-Browser
Eclipse
Automation Examples
Refactoring Summary
When to Refactor?
A multitude of indications qualifies source code for refactoring:

Repetition. Infringing the DRY principle.
Non orthogonal design.
Outdated knowledge. Things change, so do requirements,
and your own knowledge increases.
Performance. The program is too slow.
Refactor soon and often.
Automation Examples
Refactoring Summary
”Bad Smells”
Source code stinks if

code gets duplicated
methods become too long
classes become too big (too many variables)
a new feature makes too many changes necessary
code is unnecessarily general
(too many) comments are necessary
...
Automation Examples
Refactoring Summary
Catalog
Like with design patterns there are also catalogs of approved

code transformations for refactorings.
Structure:
Name (vocabulary)
Summary
of the situation within which it is required
of what it does
Motivation (when to use and when not)
Mechanism (concise, step by step instructions)
Example
Often pairwise occurrence, for both directions.
Automation Examples
Refactoring Summary
Design Methods - Extract Method
A code fragment can be grouped.

Move the fragment to its own method. The name of the method
describes its purpose.
1 void printOwing ( double amount ) {
2 printBanner () ;
3
4 // print details
5 System . out . println ( " name : " + _name ) ;
6 System . out . println ( " amount " + amount ) ;
7 }
Automation Examples
Refactoring Summary
Design Methods - Extract Method
1 void printOwing ( double amount ) {

2 printBanner () ;
3 printDetails ( amount ) ;
4 }
5
6 printDetails ( double amount ) {
7 System . out . println ( " name : " + _name ) ;
8 System . out . println ( " amount " + amount ) ;
9 }
Automation Examples
Refactoring Summary
Design Methods - Inline Method
The function body is as clear as its name.

Substitute all function calls with the function body.
1 int getRating () {
2 return m o r e T h a n F i v e L a t e D e l i v e r i e s () ? 2 : 1;
3 }
4 boolean m o r e T h a n F i v e L a t e D e l i v e r i e s () {
5 return _ nu m berOfDeliveries > 5;
6 }
1 int getRating () {
2 return ( _ n umberOfDeliveries > 5) ? 2 : 1;
3 }
Automation Examples
Refactoring Summary
Design Methods - Inline Temporary Variables
A temporary variable is assigned only once, and it is seldom used.

Replace all references to that variable by the expression.
1 double basePrice = anOrder . basePrice () ;
2
3 return ( basePrice > 1000) ;
1 return ( anOrder . basePrice () > 1000) ;
Automation Examples
Refactoring Summary
Design Methods - Introduce Descriptive Variable
There is a complicated expression.

Store the result of the expression (or parts of it) in a temporary
variable.
1 if (( platform . toUpperCase () . indexOf ( " MAC " ) > -1) &&
2 ( browser . toUpperCase () . indexOf ( " IE " ) > -1) &&
3 wasInitialized () && resize > 0) {
4 // do something
5 }
Automation Examples
Refactoring Summary
Design Methods - Introduce Descriptive Variable
1 final boolean isMacOS = platform . toUpperCase () .

indexOf ( " MAC " ) > -1;
2 final boolean isIEBrowser = browser . toUpperCase () .
indexOf ( " IE " ) > -1;
3 final boolean wasResized = resize > 0;
4
5 if ( isMacOS && isIEBrowser && wasInitialized () &&
wasResized ) {
6 // do something
7 }
Automation Examples
Refactoring Summary
Design Methods - Split Temporary Variable
There is a temporary variable, which is assigned several values.

Introduce separate variables for each assignment.
1 double temp = 2 * ( _height + _width ) ;
2 System . out . println ( temp ) ;
3
4 temp = _height * _width ;
5 System . out . println ( temp ) ;
Automation Examples
Refactoring Summary
Design Methods - Split Temporary Variable
1 final double perimeter = 2 * ( _height + _width ) ;

2 System . out . println ( perimeter ) ;
3
4 final double area = _height * _width ;
5 System . out . println ( area ) ;
Automation Examples
Refactoring Summary
Design Methods - Remove Assignment to Parameters
The code assigns a value to a (function) parameter.

Use a temporary variable.
1 int discount ( int inputVal , int quantity , int
yearToDate ) {
2 if ( inputVal > 50) inputVal -= 2;
1 int discount ( int inputVal , int quantity , int

yearToDate ) {
2 int result = inputVal ;
3 if ( inputVal > 50) result -= 2;
Automation Examples
Refactoring Summary
Organise Data - Encapsulate Field
A variable of a object is directly accessed.

Create getter- and setter-methods and use them for access.
1 private int _low , _high ;
2
3 boolean includes ( int arg ) {
4 return arg >= _low && arg <= _high ;
5 }
Automation Examples
Refactoring Summary
1 private int _low , _high ;

2
3 boolean includes ( int arg ) {
4 return arg >= getLow () && arg <= getHigh () ;
5 }
6
7 int getLow () { return _low ; }
8 int getHigh () { return _high ; }
Automation Examples
Refactoring Summary
Motivation:
subclasses can determine how values are calculated (by
overwriting the respective function)
”lazy initialization” (only initialize, when required)
Also: no public variables in classes.
Automation Examples
Refactoring Summary
Organise Data - Replace Magic Number by Symbolic

Constant
There is a number with a certain / special meaning.

Create a constant and name it after its purpose.
1 double potentialEnergy ( double mass , double height ) {
2 return mass * 9.81 * height ;
3 }
1 double potentialEnergy ( double mass , double height ) {

2 return mass * G RA VI TAT IO NA L_C ON ST ANT * height ;
3 }
4 static final double GR AV IT ATI ON AL _CO NS TA NT = 9.81;
Automation Examples
Refactoring Summary
Simplify Conditionals - Replace Nesting by ”Guards”

The normal execution path through a function is not evident.
Use ”Guards” for the special cases.
1 double getPayAmount () {
2 double result ;
3 if ( _isDead ) result = deadAmount () ;
4 else {
5 if ( _isSeparated ) result = separatedAmount () ;
6 else {
7 if ( _isRetired ) result = retiredAmount () ;
8 else result = normalPayAmount () ;
9 }
10 }
11 return result ;
12 }
Automation Examples
Refactoring Summary
Simplify Conditionals - Replace Nesting by ”Guards”
1 double getPayAmount () {
2 if ( _isDead ) return deadAmount () ;
3 if ( _isSeparated ) return separatedAmount () ;
4 if ( _isRetired ) return retiredAmount () ;
5
6 return normalPayAmount () ;
7 }
Automation Examples
Refactoring Summary
Simplify Method Calls - Rename Method
The name of a method makes its purpose evident.

Change the name.
1 getinvcdtlmt ()
1 get In v o i c e C r e d i t Limit ()
Automation Examples
Refactoring Summary
Simplify Method Calls - Separate Query from Modification
A method returns a value and additionally changes the state of the

object.
Create two methods. One for the query and one for the
modification.
1 g e t T o t a l O u t s t a n d i n g A n d S e t R e a d y F o r S u m m a r i e s ()
1 getTo ta l O ut s t an ding ()
2 setRe a d y F o r S u m m aries ()
Automation Examples
Refactoring Summary
Simplify Method Calls - Parameterize Method
Several methods do something similar, but with different values.

Create a method, which receives the value via a parameter.
1 fivePercentRaise ()
2 tenPercentRaise ()
1 raise ( percentage )
Automation Examples
Refactoring Summary
Simplify Method Calls - Introduce Parameter Object
A group of parameters belongs together.

Replace them with an object.
1 setDate ( int day , int month , int year )
1 setDate ( Date today )
Automation Examples
Refactoring Summary
Generalization - Move Field Up
Two subclasses have the same variable.

Move the variable up within the class hierarchy.
1 class Employee { };
2
3 class Salesman extends Employee {
4 String name ;
5 };
6
7 class Engineer extends Employee {
8 String name ;
9 };
Automation Examples
Refactoring Summary
Generalization - Move Field Up
1 class Employee {
2 String name
3 };
4
5 class Salesman extends Employee { };
6
7 class Engineer extends Employee { };
Automation Examples
Refactoring Summary
Summary
clean up code
revise and thereby improve the internal structure
does not change anything in the outwards visible behavior
invested time is worth it, otherwise chaos will arise
make small changes, then test
Automation Examples
Refactoring Summary
Further Reading
Refactoring - Improving the design of existing code (Martin

Fowler)
Automation Examples
Refactoring Summary
Programming Languages Classification of Programming Languages
Editors Interpreter vs. Compiler
Version Control Systems Programming Languages
Classification According to Generations
1 machine languages
2 assembler languages
3 higher programming languages
4 4GL languages
5 very high level languages
Classification According to Generations - Machine

Languages
system of instructions and data, the processor can process

directly
binary code
Classification According to Generations - Assembler

Languages
representation of a specific processor architecture machine

language in a form readable for humans
utilization of complete band width of computer
direct programming of hardware chips
usually smaller and faster as programs with similar order of
complexitiy based on high level language
higher error sensitivity
extreme high programming effort
porting on other hardware not possible
Classification According to Generations - Higher

third generation language (3GL)

introduction of standardized control structures
exact description, how a problem should be solved
task difficult to recognize from source code
Classification According to Generations - 4GL Languages
fourth generation language

application oriented
precast components
description of what the computer should do
programs usually easy to read
Classification According to Generations - Very High Level

Languages
description of issues and problems

especially in artificial intelligence
Classification According to Paradigm
1 imperative / procedural
2 functional / applicative
3 logic / predicative
4 object based
5 object oriented
Classification According to Paradigm - Imperative /

Procedural
Program as sequence of commands, the computer processes in a

defined order.
Functions and procedures serve for encapsulation and reuse of
functionality.
examples: Ada83, BASIC, C, COBOL, FORTRAN
Classification According to Paradigm - Functional /

Applicative
Computation of functions, which map input values on output

values.
example: LISP
Classification According to Paradigm - Logic / Predicative
Program consists of a set of facts and rules.
example: PROLOG
Classification According to Paradigm - Object Based
Objects are supported, further concepts, such as classes and their

relationships are missing.
example: JavaScript
Classification According to Paradigm - Object Oriented
All information necessary for problem soving (data, commands,

rules) are understood as objects.
examples: Ada95, C++, Java, Smalltalk
Interpreter vs. Compiler
interpreter:
run-time analysis of source code
→ faster development cycles
→ easy testability
→ higher flexibility
compiler:
execution of a pre-analyzed file
→ higher performance rate
Ken Thompson and Dennis Ritchie, early 1970s

further development of B (Bell Laboratories)
procedural programming language
compiler
suitable for system programming
pointer arithmetic for efficient handling of array accesses,
parameters, ...
programming closely to hardware possible, direct memory
access and pointer arithmetic
C compilers exist for nearly every processor architecture

nearly all kernels of the well-known operating systems are
implemented in C
portable and programming closely to assembler possible, as
well as abstract programming
low abstraction level
incomplete language definition (behavior partly undefined)
no data types for booleans or strings
no memory management
C++
Bjarne Stroustrup (AT&T), since 1979

further development (“increment”) of C
multiparadigm language (hybrid language), supports:
procedural programming
modular programming
structured programming
programming with self-defined data types
object oriented programming
generic programming
compiler
C++
creation of highly efficient code possible

programming closely to machine, as well as highly abstract
possible
very high expressiveness and flexibility
suitable for large projects
not property of an enterprise; standardization by ISO
historic ballast because of compatibility with C
current C++ standard library does not cover some new needs
sufficiently (e.g.: threads, TCP/IP, filesystem directories)
Java
Patrick Naughton, Mike Sheridan,

James Gosling, Bill Joy, ... (Sun
Microsystems), 1991/1992 (primary
version, “The Green Project”)
coffee preferred by the developers
objectoriented programming language
interpreter and compiler
Java
from Smalltalk:
object tree, where all objects are
hooked into and descend from one
single mother object
automatic garbage collection
virtual machine
syntax similar to C++
constructs from C++, that Java does
not have:
multiple inheritance
error-prone pointer arithmetic
overloading of operators
Ada
Jean Ichbiah (Honeywell Bull), 1970s

Lady Ada Lovelace (1815-1852)
imperative / procedural programming
language
Ada 95 supports object oriented
programming and dynamic
polymorphy
compiler
first high-level language standardized
Ada
embedded and realtime systems

strict type system (strong typing)
numerous checks during runtime
parallel processing
exception handling
generic systems
FORTRAN
John W. Backus, ... (IBM), since 1954
FORmula TRANslation
procedural, meantime also object oriented programming
language
compiler
numeric calculations
early Fortran style: goto commands
since FORTRAN 77 structured programming
since Fortran 90:
opening of the line format, originating from punchcards
optional parameters
identification of procedure parameters by name, and not only
by position in parameter list
COBOL
1960 as COBOL-60 dismissed by CODASYL

C ommon Business Oriented Language
imperative / procedural programming language
compiler
business-management area:
dealing with large data bases
input and output of large amount of data
rich of words, very close to natural language
strict separation of data declaration and procedural commands
COBOL
grouping in four parts (DIVISION) in given order:

1 Identification Division: program name and paragraphs for
comments
2 Environment Division: definition of interfaces to operating
and file system
3 Data Division: definition of program variables and data
structures
4 Procedure Division: procedural commands
and in sections (SECTION) and paragraphs (PARAGRAPH)
traditional Cobol coding scheme corresponds to punchcard
with 80 columns
BASIC
John George Kemeny and Thomas Eugene Kurtz (Dartmouth

College), 1964
Beginner’s All-purpose Symbolic I nstruction C ode
imperative programming language
interpreter
developed, to ease students the introduction into
programming with Algol and Fortran
BASIC
development principles:
easy to learn for beginners
universally applicable
expandability of the language for experts
interactivity
clear error messages
short response times
hardware independence
operating system independence
platform independence not achieved
hundreds of incompatible dialects, that only have data
handling in common
Perl
Larry Wall, 1987
citation from the Gospel according to Matthew
hybrid language
interpreter
tool for system and network administration
development of web applications
bioinformatics
combination of C with tools like sed, awk, grep and sort and
features of the bourne shell
fast problem solving and highest possible freedom for
programmer
strengths: dealing with texts and many free available modules
PHP
Rasmus Lerdorf, 1995

Personal Home Page Tools
hybrid language
interpreter
development of websites or web applications
open source software
Python
Guido van Rossum (Centrum voor

Wiskunde en Informatica,
Amsterdam), 1990s
named after Monty Python
object oriented, aspect oriented and
functional programming language
(hybrid language)
interpreter
clearness and legibility of code (e.g.:
team work, programming beginners)
Python
easy and clear (design goal):
mighty amount of functions in few
key words
grammatic syntax reduced and
optimized on clearness
possibility of embedding programs
written in other languages
programming for faster routines
closely to the machine
scripting language of other programs
(e.g.: OpenOffice.org, Blender,
PyMOL und Gimp)
Ruby
Yukihiro “Matz” Matsumoto, 1993 -

1995
gem ruby
hybrid language, supports:
object oriented programming
procedural programming
functional programming
concurrency
Ruby
interpreter
completely object oriented
Principle Of Least Surprise
Duck Typing: “When I see a bird that
walks like a duck and swims like a
duck and quacks like a duck, I call
that bird a duck.” (James Whitcomb
Riley)
LISP
Massachusetts Institute of Technology (MIT), 1995

List Processing
object oriented, functional, procedural programming language
originally FORTRAN subprograms for symbolic calculations
according to the lambda calculus
historic: programming language of artificial intelligence
“programmable programming language”: great flexibility and
extensive influence possibility for programmer
LISP = “Lots of I rritating Superfluous Parentheses”
PROLOG
Alain Colmerauer, beginning of the 1970s

Programming in Log ic
logic programming language
based on mathematical fundamentals of first order logic
collection of Horn clauses
database, containing facts and rules
application areas:
1980s: construction of expert systems
today: natural language processing, artificial intelligence
Smalltalk
Alan Kay, Dan Ingalls, Adele Goldberg (Xerox PARC
Forschungszentrum), 1970s
object oriented programming language
interpreter
developed for teaching
expert systems (beginning and middle of 1990s)
dynamic typing
no multiple inheritance
automatic garbage collection
influenced by Lisp and Simula
influence on development of later programming languages
(e.g.: Java, Ruby)
Further Reading
Taschenbuch Programmiersprachen - overview with examples,

bibliography, ...
Editor
Programming Languages Editor Functions
Editors jEdit
Version Control Systems Eclipse
Summary
Tools
A carpenter works with the raw material wood.

A programmer works with text.
Editor
Editors jEdit
Summary
Editor
Tools should become an elongation of the hands.

Text has to be easy to work with, since it is the elementary
raw material of a programmer.
Concentrate on one editor, and master it (shortcuts).
Use this editor for source code, documentation and other data.
Editor
Editors jEdit
Summary
Editor
When using several programs make sure that (as many)

shortcuts (as possible) are the same.
Shortcuts have to become a reflex.
Choose an editor which is available on many platforms.
Editor
Editors jEdit
Summary
Editor Functions
Elementary features, that an editor should have

configurability
extensibility
programmability
Editor
Editors jEdit
Summary
Configurability
Every aspect should be configurable to one’s preferences:

font
colors (syntax highlighting)
window sizes
shortcuts (all editing operations should be usable via keyboard
shortcuts; ”invisible operations” can be done via shortcuts)
Editor
Editors jEdit
Summary
Extensibility
Plugins offer the possibility to extend the editor with new

funcionality.
Editor should not become out of date, when a new
programming language or data format appears (e.g. syntax
highlighting).
It should be possible to integrate each compiler environment
(calling the specific tools).
Editor
Editors jEdit
Summary
Programability
Editor should be programmable for complicated tasks (which

involve several steps).
macros
built in scripting language (e.g. Emacs-Lisp)
Editor
Editors jEdit
Summary
Productivity
Cursor movement:
Shortcuts which move the cursor in units of words, lines, block or
functions are more efficient than repeatedly pressing a key.
New file:
Editor can offer a template dependent on the file type
class and module names
author name and copyright texts
frameworks for declarations (e.g. constructor, destructor)
Editor
Editors jEdit
Summary
Productivity
Automatic indentation:
After pressing Return (or even after pressing e.g. ’{’) a new line is
correctly indented.
Sorting lines:
Emacs: M-x sort-lines
Editor
Editors jEdit
Summary
Programming Language Specific Functions
syntax highlighting (wrongly written key words are detected

faster)
autocompletion
automatic indentation
text templates
integrated help system
IDE like features
e.g. start the compiler or debugger
directly jump to lines containing errors
Editor
Editors jEdit
Summary
jEdit
www.jedit.org (Java)
Editor
Editors jEdit
Summary
Editing Modes
jEdit offers several modes for many data formats and programming
languages. A mode describes:
syntax highlighting
indentation style
soft vs. real tabs
Editor
Editors jEdit
Summary
Shortcuts
Open menus:
Alt-UnderlinedLetter, then underlinedLetter
Files:
open: Ctrl-O (Select files by entering the initial letters)
save: Ctrl-S
Editor
Editors jEdit
Summary
Shortcuts - Navigation
Navigation:
Goto line: Ctrl-L
Ctrl-LEFT, -RIGHT, -UP, -DOWN
go to corresponding parenthesis: Ctrl-]
select code block: Ctrl-[
previous bracket: Ctrl-E Ctrl-[
next bracket: Ctrl-E Ctrl-]
Editor
Editors jEdit
Summary
Shortcuts - Editing
Editing:
undo: Ctrl-Z
copy: Ctrl-C
cut: Ctrl-X
paste: Ctrl-V
delete line: Ctrl-D
delete word behind cursor: Ctrl-DEL
delete to line end: Ctrl-Shift-DEL
delete word before cursor: Ctrl-BACKSPACE
delete to line start: Ctrl-Shift-BACKSPACE
Editor
Editors jEdit
Summary
Shortcuts - Comfort
Others:
complete word: Ctrl-B
expand abbreviation: Ctrl-; (or pressing space at the end of
the abbreviation)
Editor
Editors jEdit
Summary
Shortcuts - Buffers
Buffers:
previous buffer: Ctrl-PAGE UP
next buffer: Ctrl-PAGE DOWN
last buffer: Ctrl-BACK QUOTE
buffer list: Alt-BACK QUOTE
Splitting:
horizontal: Ctrl-2
vertical: Ctrl-3
Switching between text areas:
next: Alt-PAGE UP
previous: Alt-PAGE DOWN
Editor
Editors jEdit
Summary
Action Bar
Action Bar (Ctrl-RETURN):

most editor features are accessible via keyboard this way
repetitions: #repetitions key / action
history: menu actions and toolbar clicks are saved here, too
pressing TAB shows a list of possible actions (does not only
search at the beginning, but also in the middle of the names);
RETURN selects the first element of the (invisible) list
change properties (buffer.tabSize=4)
Editor
Editors jEdit
Summary
Search and Replace
incremental search: Alt-COMMA

all occurrences of an expression: Alt-PERIOD
regular expressions
replace by BeanShell snippets
Editor
Editors jEdit
Summary
Macros
record a temporary macro: Ctrl-M Ctrl-M

play temporary macro: Ctrl-M Ctrl-P
record named macro: Ctrl-M Ctrl-R
stop recording: Ctrl-M Ctrl-S
repeat / play last macro: Ctrl-Shift-B
Very useful: Record a macro, save it and assign a keyboard
shortcut.
Macros are BeanShell scripts.
Editor
Editors jEdit
Summary
BeanShell
Macro programming language

Java syntax
allows access to jEdit classes
Utilities>BeanShell>Evaluate Selection: interprets selection
as BeanShell code and replaces the selection by the result
(e.g. ”(2*3) + 4”)
Editor
Editors jEdit
Summary
Temporary Storage
There is not only one storage place, but (almost) arbitrary many:
called a register
copy to register: Ctrl-R Ctrl-C key
cut from register: Ctrl-R Ctrl-X key
copy from register: Ctrl-R Ctrl-V key
register contents are stored between editing sessions
Editor
Editors jEdit
Summary
Markers
Markers mark positions within the source code:

insert / delete marker: Ctrl-E Ctrl-M
next marker: Ctrl-E Ctrl-COMMA
previous marker: Ctrl-E Ctrl-PERIOD
insert named marker: Ctrl-T key
go to named marker: Ctrl-Y key
Editor
Editors jEdit
Summary
Folding
Folding (hiding source code):

collapse fold: Alt-BACKSPACE
collapse one level: Alt-RETURN
collapse all levels: Alt-Shift-RETURN
collapse all folds: Ctrl-E C
expand all folds: Ctrl-E X
Narrowing (contrary of folding):

only display current fold: Ctrl-E N N
only display current selection: Ctrl-E N S
Editor
Editors jEdit
Summary
Cool Features
compresses and decompresses GZipped files automatically

automatic saving, and crash recovery
backups (saves several versions of a file)
handles character encodings with ease
tooltips for icons display corresponding keyboard shortcut
rectangle and multiple selection of text
Editor
Editors jEdit
Summary
Plugins
Many plugins available:

applications (e.g. calculator)
enterprise (e.g. SQL)
file management (e.g. FindFile)
formatting and analysis (e.g. AStyle Beautifier)
HTML and XML (e.g. JTidyPlugin)
Java (e.g. JExplorer)
Editor
Editors jEdit
Summary
Plugins
language support (e.g. ClassWizard)

network (e.g. FTP)
projekt management (e.g. JCounter)
support (e.g. ShortcutDisplay)
text (e.g. RETest)
version control (e.g. GruntspudPlugin)
visual (e.g. Highlight)
Editor
Editors jEdit
Summary
Eclipse
www.eclipse.org (Java)
Editor
Editors jEdit
Summary
Eclipse - Cool Features
class browser
auto-completion
compilation errors are immediately displayed
Ctrl-LMB on a function or variable name jumps to its
definition point
new variables and functions are immediately displayed in the
class browser
refactoring
mouse (tool)tips show Javadoc help or a declaration
Editor
Editors jEdit
Summary
Summary
use one editor, and master it

configurability
extensibility
programmability (macros, scripting language)
learn shortcuts (!), should become a reflex
syntax highlighting, auto completion, automatic indentation,
text templates, help system, start external tools
eclipse, jedit, (emacs)
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Motivation
access to older versions

editing of files by multiple users
branching
logging of changes
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Repository
Definition
The repository is a central place for depositing all files of a
project. It contains all information, necessary for reconstruction of
former versions of a project file.
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Sandbox
Definition
A sandbox serves for deposition of working copies of the file
versions from the repository on the local computer. For each
repository, there may be any number of sandboxes, e.g. for
different development levels of the same project.
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Actions
import of data
adding data
fetching data
committing data
editing files
removal of files
tagging files
updating of the data
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Import of Data
creation of an (empty) repository

no sandbox does exist yet
first adding of local project files to the repository
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Adding Data
data not existing in repository

data existing in sandbox
adding new data from sandbox to repository
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Fetching Data
data exisiting in repository

data not existing in sandbox
fetching files from repository to sandbox
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Committing Data
repository holds older version of data

edited version of data in sandbox
adding of edited data from sandbox to repository
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Editing Files
preparation of file for editing

marking of file for information of other editors
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Removal of Files
removal of files / directories from repository
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Tagging Files
tagging of files, directories, branches, ...

version number, ...
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Updating of the Data
update of data in sandbox

differences of data in repository and in sandbox are displayed
files existing in an older version in the sandbox, are replaced
by newest version from repository
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Examples for Version Control Systems
RCS
SCCS
VSS
Rational ClearCase
CVS
SVN
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
RCS
Revision Control System

1980s
Walter F. Tichy
Purdue University
GNU project
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
SCCS
Source Code Control System

1972
Bell Labs
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
VSS
Visual SourceSafe
Microsoft
VisualBasic, C++, C
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Rational ClearCase
1980s
IBM
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
CVS
Concurrent Versions System

development since 1989
GNU general public license
further development of RCS and SCCS
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Exercise: Version Control
Environment variables:
1 export CVS_RSH = ssh
2 export CVSROOT =: ext : user@machine :/ path / to /
cvsrepository
3 [ export CVSROOT =/ path / to / cvsrepository ]
Creating a repository:
1 mkdir ~/ cvsrepository
2 cvs -d / path / to / cvsrepository init
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Creating a new project:

1 mkdir ~/ EPtest
2 cd ~/ EPtest
3 kwrite helloWorld . cpp
4 cvs import EPtest " yourname " " initial "
5 cd
6 rm - rf EPtest
7 cvs checkout EPtest
8 cd EPtest
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Adding files:
1 cvs add helloUniverse . cpp
2 cvs commit helloUniverse . cpp
Commit changes:
1 cvs edit helloWorld . cpp
2 cvs commit helloWorld . cpp
Update:
1 cvs update
2 [ cvs update helloWorld . cpp ]
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
WinCVS
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Cervisia (KDE)
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
SVN
Subversion
development since 2000
CollabNet
replacement for CVS
conversion of a CVS repository with cvs2svn
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
SVN
advantages compared with CVS:

versioning of directories
renaming of files (and directories) has no influence on file
history
search for differences between files with algorithm, working for
text as well as binary files
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
SVN
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Further Reading
CVS kurz & gut - overview on most important commands

Versionskontrolle mit Subversion
Technical Terms
Actions
Examples
Editors
CVS
SVN
Further Reading
Complexity
Special Languages
Debugging
Source Code Generators
Parsing Files
Testing
Summary
Software Becomes More and More Complex
in the early days there were character oriented terminals

nowadays you have graphical user interfaces with
context sensitive help
cut and paste
drag and drop
Applications are getting more complex (multi tier architecture).
Programs should be dynamic and flexible and work together with
third party applications.
Programming is getting more and more complex.
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Wizards
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
New Tools
Today you need other tools than 20 years ago.

”Assistents” create a source code framework with only few inputs.
(Afterwards they do not help you anymore...)
But be careful: If you do not understand the created source code
you are programming with chance.
Do not use generated source code, that you do not understand.

Otherwise you might soon lose control.
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Difference Between Foreign and Own Code
You often also do not understand the implementations of used

libraries. But they are encapsulated and accessible through well
defined interfaces.
But generated source code becomes a part of your program.
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Special Languages
“The limits of my language mean the limits of my world.”

(Ludwig Wittgenstein)
Programming languages influence how you think about
problems.
Program close to the problem, i.e. develop your own simple
language.
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Special Languages
Data description languages: create data structures, which are

used by the application
sendmail-configuration
menus, control elements, dialogs in Windows ressource files
Imperative languages: are translated to executable code
translation from a special language to e.g. C++-code
scripting languages, which get interpreted within an
application (e.g. Beanshell in jEdit)
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Templates
When a carpenter has to produce the same piece again and again
he creates a template.
simplifies the task
reduces the risk to make mistakes
The craftsman can concentrate on the quality.
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Source Code Generator
Equivalently, a programmer can write a source code generator.

There are two kinds of source code generators:
Passive: are executed once; from that point on the result
becomes independent
assistants
some CASE tools
Active: are executed each time when the result is required.
The result is a product for one-time usage since it can be
recreated whenever necessary.
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Passive Source Code Generators
Passive source code generators save typing effort. They are

parameterized templates which create a specified output from a set
of input data.
Intended use:
creation of new source code files: e.g. templates, copyright
texts, standard comments, code framework
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Passive Source Code Generators
One-time conversions between programming languages: e.g.

troff to LATEX. Conversions do not have to be perfect; small
corrections are acceptable.
Creation of lookup tables (LUT) and other ressources, which
are time consuming to calculate during program runtime.
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Active Source Code Generators
Passive source code generators are convenient, while active ones

are necessary if you want to follow the DRY principle (converting
one single piece of knowledge to all necessary forms).
Every time you try to make different environments interact, you
should think about active source code generators.
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Active SCGs - Example DB
Development of a database application, 2 environments: DB and

programming language.
Create the source code from the database scheme. If the scheme
changes you simple recreate the source code. If a column
disappears the respective field in the data structure gets removed,
too.
1 struct EmployeeRow
1 Scheme 2 ...
2 Table ’ Employee ’ 3 struct EmployerRow
3 Table ’ Employer ’ 4 ...
4 Table ’ Benefit ’ 5 struct BenefitRow
6 ...
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Active SCGs - Example Programming Languages
When multiple programming languages are used within an

application you need common information for their communication
(data structures, message formats).
Either create the data for one language from the other.
Often it is easier to formulate the information in a simple,
language independent format, and generate source code for
both languages.
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Active SCGs - Example Programming Languages

1 # Add a product
2 # to the ’on - order ’ list
3 M AddProduct
4 F id int
5 F name char [30]
6 F order_code int
1 { Add a product }
1 /* Add a product */
2 { to the ’on-order’ list }
2 /* to the ’on-order’ list
3 AddProductMsg = packed
*/
record
3 typedef struct {
4 id : LongInt ;
4 int id ;
5 name : array [0..29] of
5 char name [30];
char ;
6 int order_code ;
6 order_code : LongInt ;
7 } AddProductMsg ;
7 end ;
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Active SCGs - Example UML to Source Code
creation of source code from UML diagrams

e.g. with Umbrello
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Intelligent SCGs
It is also possible to do it ”two-way”: Eclipse adapts the view of a

class in the class browser, when the source code is changed and
the other way round. But it only creates source code frameworks.
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
SCG - Keep it simple
SCGs ideally are kept very simple

parsing of the control files actually is the bigger problem
also keep the data format simple!
creation of the source code consists mainly of print statements
SCGs can be used for any output (HTML, LATEX, ...)
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Exercise: SCGs
start the program ’umbrello’

create at least one class
add attributes and methods
set the output path
select a programming language
let the program create the source code for you
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Parsing
Analysing the structure of a file consists of two tasks:

1 subdivide the file into single tokens
2 recognize the hierarchical structure
To that end there exist the programs flex (lex) and bison (yacc).
They are mainly used in compiler creation.
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
(f)lex
flex: a fast scanner generator

divides an input stream into its single units
controlled by regular expressions and corresponding program
fragments
flex analyse.lex
creates C[++]-Code, which segments the files according to
the regular expressions (deterministic finite automaton)
gcc lex.yy.c
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Structure of a flex file
Definition part
%%
Rule part
%%
User defined routines
The rule part looks like this:

r1 a1;
r2 a2;
rn an;
An action consists of one or more C[++] statements.
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
example.lex
1 /* tells flex to provide a default main function */

2 % option main
3
4 /* rules below */
5 %%
6 a |
7 e |
8 [ iou ] printf ( " \ nVowel % s recognized \ n " , yytext ) ;
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Segmentation using example.lex
The input
1 abcdefghijklmnopqrstuvwxyz
will be subdivided into the following units:

1 abcd
2 e
3 fgh
4 i
5 jklmn
6 o
7 pqrst
8 u
9 vwxyz
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
bison (yacc)
yacc: yet another compiler-compiler (compiler generator)

analyses the structure of a data stream
controlled by a LALR(1) context free grammar (BNF) and
respective code
bison analyse.y
generates C[++] code, which upon encountering a structure,
executes the corresponding code
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Structure of a bison file
Definition part
%%
Rule part
%%
User defined routines
The rule part looks like this:

leftHandSide : rightHandSide a1;
leftHandSide : rightHandSide a2;
leftHandSide : rightHandSide an;
An action consists of one or more C[++] statements.
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Other Languages
flex and bison generate C[++] code

is also available for other languages (e.g. javacc)
http://catalog.compilertools.net
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Summary
using assistants is OK, if you understand the generated source

code
keep the format of the control file simple
you cannot only generate source code, but any kind of file
(HTML, Text, ...)
Complexity
Special Languages
Debugging
Parsing Files
Testing
Summary
Further Reading

Compilers - Principles, Techniques and Tools (Aho, Sethi,
Ullman)
Debugging
Creation / Adaption of Source Code Psychology of Debugging
Debugging Strategies for Debugging
Creation of Documentation Debugger
Testing Useful Programs
Summary
The 1. Bug
Debugging
Summary
Debugging
“It is a painful thing to see your own problems and to realize that
only you and nobody else caused them.” (Sophokles)
Debugging
Summary
Psychology of Debugging
nobody writes perfect software

approximately 50 % of the time is spent searching errors
debugging should simply be viewed as problem solving
Whose fault is it? It doesn’t matter. Simply solve the
problem.
Debugging
Summary
Mentality for Debugging
“The easiest person to deceive is one’s self.” (Edward

Bulwer-Lytton)
relax
make yourself comfortable
Don’t panic!
think about (calmly) were the causes could lie
find the root of the problem; do not simply remove symptoms
Debugging
Summary
Where to begin?
before you start, make sure that the source code compiles
without warnings
exact error description, gather relevant information
ask the person, who detected the mistake
artificial tests do not test the application sufficiently
check boundary cases and realistic input
make the error reproducable (with as few steps as possible)
Debugging
Summary
Visualize Data
display edited data

as plain text
graphically
use a debugger, that can display data and their relations
data displayed as a 3D landscape
as a structure diagram
pencil and paper
Debugging
Summary
Tracing
watch the state of the program or a data structure over the

course of time
print diagnosis messages on screen or to a log file
use a regular, consistent format; this allows an automatic
analysis
Debugging
Summary
Rubber Ducks
a simple and useful technique for the analysis of a problem:

explain it to someone else
this could be a rubber duck :-)
this stepwise explanation often leads to understanding the
cause of the problem
this way things are explicitly mentioned which are usually
taken for granted
Debugging
Summary
Process of Elimination
usually the error lies within one’s own code and not within the
used libraries
reading the manual helps, if you think that something should
work in a specific way, but it does not
use the binary method for debugging
Debugging
Summary
Elements of Surprise
Sometimes the error lies within a function of which you

thought that it worked absolutely correct.
Do not assume that something works in a specific way; prove
it.
Are there other places within the program which are
susceptible for this kind of error? Correct them now, too.
If it took you a long time to find an error, think about how
you could do it faster next time.
Debugging
Summary
Dead Programs Do Not Lie
Always make sure that functions are terminated successfully

(by checking their return values).
Program defensively: Try to detect problems as early as
possible.
Let programs crash (but clean up before if possible), otherwise
you might continue with questionable data.
Java e.g. thows runtime exceptions.
Debugging
Summary
Secured Programming
“There is a luxury in self-reproach. When we blame ourselves we

feel that no one else has a right to blame us.” (Oscar Wilde)
”This can never happen...” It can!
Prevent the impossible from happening by using assertions.
C[++]: assert macro
1 void writeString ( char * string ) {
2 assert ( string != NULL ) ;
3 ...
Debugging
Summary
Secured Programming
The condition within an assertion must not exhibit any side

effects (i.e. there must not be any code which has to be
executed within the brackets).
Heisen-Bug: debugging which influences the behavior of the
application
Assertions should be left on all the time.
Debugging
Summary
Design by Contract
goes one step further than assertions

documents rights and responsibilities of software modules
preconditions: have to be valid, otherwise the function must
not be called
postconditions: guaranteed state after the termination of the
function
class invariants: the class makes sure that these conditions
always hold for the caller
write code that is unwilling to work: be rigorous with what
you accept and promise as less as possible
supported by Eiffel, iContract for Java, Nana for C[++]
Debugging
Summary
Design by Contract - Example (iContract)
1 /**
2 * @invariant forall Node n in element() |
3 * n.prev() != null
4 * implies
5 * n.value().compareTo(n.prev().value()) > 0
6 */
7 public class dbc_list {
8 /**
9 * @pre contains(aNode) == false
10 * @post contains(aNode) == true
11 */
12 public void insertNode ( final Node aNode ) {
13 // ...
Debugging
Summary
GDB
Debugging
Summary
GDB
GNU debugger
console debugger for C[++] and Modula-2, Fortran, Java,
Pascal, Assembler and Ada
step (by step) through a program
displays values of variables
you can set breakpoints at arbitrary points, or when certain
conditions are met
works very well, but is rather uncomfortable
Debugging
Summary
DDD
graphical front-end for console debuggers (like GDB, DBX,

Ladebug, XDB)
also supports Java (via jdb), Python (pydb), Perl and Bash
displays data structures and their relations well arranged
Debugging
Summary
DDD
Debugging
Summary
Valgrind
lets programs run in a virtual machine

finds memory leaks
cachegrind checks runtime characteristics (profiler)
Debugging
Summary
Flawfinder
analyzes source code statically (built-in DB of C/C++

functions with known problems, simple pattern matching)
finds frequent errors
similar tools: splint, RATS (Rough Auditing Tool for Security)
Debugging
Summary
Strace
Shows open files and system calls.

amount and duration of system calls
1 strace -c ls -l
file accesses
1 strace -e trace = file ls -l
network accesses
1 strace -e trace = network firefox
Debugging
Summary
Exercise: Useful Programs
download
http://www.dwheeler.com/flawfinder/flawfinder-1.27.tar.gz
tar xvfz flawfinder-1.27.tar.gz
cd flawfinder-1.27
let flawfinder analyze the accompanying example files
Debugging
Summary
Summary
50 % of the time spent searching errors, don’t panic!

employ binary error search
heed compiler warnings
gdb, ddd as front end
debuggers useful to get to know programs
tracing (logging)
rubber ducks
Debugging
Summary
Further Reading

Documentation
Debugging
Documentation Tools
Summary
Testing
Documentation
“The palest ink is better than the best memory.” (Chinese

Proverb)
Documentation
Debugging
Documentation Tools
Summary
Testing
Documentation
Documentation should be viewed as an integral part of

software development.
Documentation is easier if
work is not repeated multiple times
documentation is kept in reach
Donald Knuth: ”Literate Programming” (writing of computer
programs in a form, which is above all readable by humans)
Javadoc, etc.
Documentation
Debugging
Documentation Tools
Summary
Testing
Documentation
Source code and documentation are two views on the same

model.
Documentation is a mirror of the source code. In case of
discrepancies the source code is right.
English should be handled like a programming language (i.e. all

pragmatic principles can be applied to documentation, too).
Documentation should be integrated rather than just attached.
Documentation
Debugging
Documentation Tools
Summary
Testing
Types of Documentation
There are 2 types of documentation:

internal
source code comments
design and test documents
requirements specification
external
everything which is delivered or published to the outside world
(e.g. instruction manuals)
Documentation
Debugging
Documentation Tools
Summary
Testing
Source Code Comments
Documentation can be created from comments and declarations in

the source code. Source code needs comments, but too many are
as bad as too few.
Comments should explain why something is done the way it is
done (Purpose and goal, reasons for compromises, alternatives).
How it is done already is described in the code itself (and should
therefore not be commented).
Documentation
Debugging
Documentation Tools
Summary
Testing
The following should be commented:

the module
data types
classes
functions
describes how the function can be called, and what has to be
considered
Documentation
Debugging
Documentation Tools
Summary
Testing
What should not be in souce code comments:

a list of functions exported by this file
a changelog (version control systems store that for you)
a list of used files
the name of the file
There are external programs, which analyze source code, and
determine this kind of information for you.
Documentation
Debugging
Documentation Tools
Summary
Testing
Executable Documents
create SQL statements and data structures form database

specifications
use e.g. Perl to process the draft (if it is in plain text)
if the draft is stored in a proprietary format:
write a macro (in the application’s macro language)
or export it as plain text
now if the specification changes new ”views” on the ”model”
can easily be generated automatically
Documentation
Debugging
Documentation Tools
Summary
Testing
Technical Authors
external documentation like instruction manuals and

advertising material is often written by technical authors
they also should have access to automatically generated
documentation
Documentation
Debugging
Documentation Tools
Summary
Testing
Printing vs. Web Publishing
Documentation on paper becomes obsolete as soon as it is

printed.
Documentation should preferably (also) be published in a
form which can be published (with hyperlinks) on the web.
is easier to keep up to date
Documentation often has to be published in different formats
(instruction manual, web page).
do not use cut and paste!
generate everything automatically from one source
or use a word processing program which can export the
required formats
Documentation
Debugging
Documentation Tools
Summary
Testing
Markup Languages
use markup languages for (big) documentation projects

DocBook (SGML based)
can be converted to many different formats (TeX, PS, HTML)
Documentation
Debugging
Documentation Tools
Summary
Testing
Documentation Tools
documentation within the source code (DRY)
javadoc, doxygen, DOC++
allow to browse source code (even without additional
comments)
visualization of inheritance diagrams and dependency graphs
Documentation
Debugging
Documentation Tools
Summary
Testing
Doxygen
supports many programming languages: C[++], Java,

Python, ...
several output formats: HTML, LaTeX, PostScript, PDF,
Man page, ...
Documentation
Debugging
Documentation Tools
Summary
Testing
Doxygen
Documentation
Debugging
Documentation Tools
Summary
Testing
Exercise: Creation of Documentation
add comments to your umbrello UML class model

let umbrello create Java source code
run javadoc to create a documentation of your model
Documentation
Debugging
Documentation Tools
Summary
Testing
Summary
Documentation and source code are (should be) two views

onto the same model.
Integrate documentation into the source code (DRY).
Use javadoc, doxygen.
Generated API documentation can be used to browse the
source code.
Documentation
Debugging
Documentation Tools
Summary
Testing
Further Reading

Motivation
Kinds of Tests
Creation / Adaption of Source Code Testable Features
Debugging Test Process
Creation of Documentation Regression Test
Testing Black Box Test
Glass Box Test
Summary
Testing
Motivation
Kinds of Tests
Glass Box Test
Summary
Motivation
code and fix: coding or correction alternating with ad hoc

tests (inefficient, but widely used)
testing is a core process in a development process
cooperation of multiple components
avoid rectification work (after delivery):
customer should receive working software
customer should receive complete software (according to
specification)
errors are not always obvious
Motivation
Kinds of Tests
Glass Box Test
Summary
Kinds of Tests
What ist to be tested?

module test (Low-Level)
integration test (Low-Level)
system test (High-Level)
acceptance test (High-Level)
→ compare core processes of a development process
How do we test?
regression test
black box test
glass box test
Motivation
Kinds of Tests
Glass Box Test
Summary
Module Test
unit test
component test
check on correctness of software module
automated (test program)
preliminary stage to integration test
required for refactoring:
module test after each change
Motivation
Kinds of Tests
Glass Box Test
Summary
Integration Test
test on cooperation of depending components

before: test of each single component
check of each single component after combination
check of data exchange via common interface(s)
bottom up method:
integration test for differentiated subsystem
subsystem seen as component
Motivation
Kinds of Tests
Glass Box Test
Summary
System Test
test of complete system against specification

functional system test:
check on correctness and completeness
non functional system test:
check on security, usability, reliablility, ...
Motivation
Kinds of Tests
Glass Box Test
Summary
Acceptance Test
test via customer / user

check on requirements from specification
Motivation
Kinds of Tests
Glass Box Test
Summary
Testable Features
functionality
installation
recommissioning
availability
Motivation
Kinds of Tests
Glass Box Test
Summary
Functionality
specification fulfilled?
Motivation
Kinds of Tests
Glass Box Test
Summary
Installation
installation possible?
commissioning possible?
documentation complete?
Motivation
Kinds of Tests
Glass Box Test
Summary
Recommissioning
restart after interruption possible?

documentation complete?
Motivation
Kinds of Tests
Glass Box Test
Summary
Availability
system run for requested time span

failure?
Motivation
Kinds of Tests
Glass Box Test
Summary
Preparation
determination of test cases:

initial state
values of input data
operations
expected outputs
Motivation
Kinds of Tests
Glass Box Test
Summary
Preparation
creation of test plan:

comparison with specification
reuse
expansion
Motivation
Kinds of Tests
Glass Box Test
Summary
Preparation
The test should not be done by the developer himself, if possible.

But, a test by the developer is still better than no test at all.
Motivation
Kinds of Tests
Glass Box Test
Summary
Rules
no premature stop
no special test variant of the program
no alternating between test and debugging
Motivation
Kinds of Tests
Glass Box Test
Summary
Stop Criterions
after defined maximum duration

after defined effort
after defined runtime without error
execution of all specific test cases yields specified results
average test costs per detected error exceed defined value
defined number of errors detected
Motivation
Kinds of Tests
Glass Box Test
Summary
Evaluation
check, if program does exactly what it should do and nothing

else
test report:
administrative information (module name, date, ...)
final evaluation
links to documents concerning the test
determined deviations (⇒ problem message)
base for planning and control of debugging
Motivation
Kinds of Tests
Glass Box Test
Summary
Regression Test
change of software:
bugfix
expansion
check on spillovers by modification of already tested software
repetition of all test cases
test results identical with those of previous version (apart
from desired differences)
automated execution possible
Motivation
Kinds of Tests
Glass Box Test
Summary
Function Test
comparison with specification

choice of test data according to desired functionality of
program
Motivation
Kinds of Tests
Glass Box Test
Summary
Function Coverage
check all functions of program

list functions from specification
describe test case for each function
Motivation
Kinds of Tests
Glass Box Test
Summary
Input Coverage
treatment of all different input combinations

list input combinations from specification
describe test case for each input possibility
Motivation
Kinds of Tests
Glass Box Test
Summary
Output Coverage
create all possible outputs

list output possiblities from specification
describe test case(s) for every possible output
Motivation
Kinds of Tests
Glass Box Test
Summary
Example - Test Item
Motivation
Kinds of Tests
Glass Box Test
Summary
Example - Requirements
no description
R01 may be used for transport
R02 easy to handle
R03 has no problems with rough territory
... ...
Rnn non-polluting
Motivation
Kinds of Tests
Glass Box Test
Summary
Example - Function Coverage
no description input output comment

F01 transport (R01) cram and baggage is ok
launch transported
F02 easy to handle lead from A moves from failed
(R02) to B A to B (stubborn)
F03 no problems lead through moves through ok
with rough rough territory rough territory
territory (R03)
... ... ... ... ...
Fnn non-polluting fuel non-polluting ok
(Rnn) fall-out
Motivation
Kinds of Tests
Glass Box Test
Summary
Example - Input Coverage
no input demanded reaction comment

E01 command “go” moves straight ahead failed
(works often)
E02 command “left” turns left failed
(unreliable)
E03 command “right” turns right failed
(unreliable)
E04 command “stop” stands still failed
(unreliable)
... ... ... ...
Enn manual pushing moves straight ahead ok (unwilling)
Motivation
Kinds of Tests
Glass Box Test
Summary
Example - Output Coverage
no demanded output required input comment

A01 moves straight command “go”; manual ok
ahead pushing, if necessary
A02 stands still command “stop”, ok
hold, if necessary
A03 fully loaded hold and load ok
... ... ... ...
Ann movement in command “right”, “left” ok
correct direction or manual pushing (unwilling)
Motivation
Kinds of Tests
Glass Box Test
Summary
Exercise: Testing
no req. inp. outp. comm.

F01 R01
F02 R02
F03 R03
... ... ... ... ...
Fnn Rnn
Motivation
Kinds of Tests
Glass Box Test
Summary
Exercise: Testing
Motivation
Kinds of Tests
Glass Box Test
Summary
Structure Test
check of processes
choice of test data depending on internal structure of program
Motivation
Kinds of Tests
Glass Box Test
Summary
Command Coverage
check of as many commands as possible

ideal case: check of all commands
coverage indicated as proportion:
x % of all commands have been executed in the test
Motivation
Kinds of Tests
Glass Box Test
Summary
Branch / Decision Coverage
check of as many branching possibilities as possible

ideal case: check of all branching possibilities
x % of all branching possibilities have been run through in the
test
Motivation
Kinds of Tests
Glass Box Test
Summary
Term Coverage
execution of as many logic terms as possible

ideal case: execution of all logic terms
x % of the logic terms have been executed in the test
Motivation
Kinds of Tests
Glass Box Test
Summary
Handling of Loops
avoidance of loop
one iteration
two iterations
typical number of iterations
maximum number of iterations
Motivation
Kinds of Tests
Glass Box Test
Summary
Path Coverage
execution of as many paths through the program as possible

ideal case: execution of all possible paths
x % of possible paths have been run through in the test
Motivation
Kinds of Tests
Glass Box Test
Summary
Program Entity Coverage
coverage criterion for program components

each component is called at least once
Motivation
Kinds of Tests
Glass Box Test
Summary
Call Coverage

each callable part of entities of a program is called at least
once
Motivation
Kinds of Tests
Glass Box Test
Summary
Programmpath Coverage

all possible execution sequences of program entities are run
through at least once
Motivation
Kinds of Tests
Glass Box Test
Summary
Summary
module test on check of program components

integration test for check on cooperateion of multiple
components
system test for check on whole system
acceptance test by customer
black box test for check on functionality
glass box test for check on structure
black and glass box test complement one another
Testing is important!
Motivation
Kinds of Tests
Glass Box Test
Summary
Further Reading
source: lecture notes “Software-Engineering” (state: May

1997)
Prof. Dr. rer. nat. Jochen Ludewig
http://www.iste.uni-stuttgart.de/se/se.html

SeminarEPMuW ENWAT

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SeminarEPMuW ENWAT

Hochgeladen von

Copyright:

Verfügbare Formate

Efficient Programming - Methods and Tools

Dipl.-Inf. Martin Barbisch, Dipl.-Inf. Ursula Vollmer

1 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

2 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

Object Oriented Programming

3 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

4 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

5 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

Creation / Adaption of Source Code

6 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

programming very complex

7 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

facilitation of large as well as small programming tasks

8 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

Object Oriented Programming

basic idea: mapping of real world in program

9 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

object structure defined by attributes (features) of its class

10 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

grouping of objects according to similar features

11 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

inheritance of data structure (attributes) and methods

12 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

13 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

14 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

15 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

16 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

17 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

18 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

19 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

object blue tit (e.g.):

20 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

referencing of class attributes without knowing the precise

21 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

only interface known

22 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

23 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

Motivation (Process Models)

code and fix: coding or correction alternating with

24 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

25 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

26 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

27 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

28 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

Validation & Verification

module tests (low level test):

29 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

30 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

31 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

Design Patterns - Motivation

solutions for recurring design problems

32 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

Design Patterns - What are Design Patterns?

The context is a situation, in which the pattern is applied.

33 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

Design Patterns - The Inventors

Design Patterns (1995), Gamma, Helm, Johnson, Vlissides

Design Patterns - Categories of Patterns 1

Design Patterns - Categories of Patterns 2

There are also patterns for many other areas.

36 Martin Barbisch, Ursula Vollmer Efficient Programming - Methods and Tools

Design Patterns - Shared Vocabulary