COSC3311 – Software Design
Gotos, Breaks and Structured
Programming
Department of Computer Science, York University
Slides based on Object Oriented Software Construction
2016-03-22 3:24 AM
0
What’s wrong with `break’
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Subject: AT& T Bug
Date: Fri Jan 19 12: 18: 33 1990
This is the bug that caused the AT& T breakdown the other day:
In the switching software (written in C),
there was a long do . . . while construct,
which contained a switch statement,
which contained an if clause,
which contained a break,
which was intended for the if clause,
but instead broke from the switch.
 A missing “break” statement brought down the entire longdistance telephone network in the North Eastern US,
resulting in millions of dollars of damage!
Department of Computer Science, York University
Slides based on Object Oriented Software Construction
2016-03-22 3:24 AM
1
Statement from Bertrand Meyer
 eiffel_sofware@groups.yahoo (Feb 2004)
 “I assume the question about "powerful weapons"
refers to the break / continue control structures of
C and Java.
 BM’s response follows on the next few pages:
Department of Computer Science, York University
Slides based on Object Oriented Software Construction
2016-03-22 3:24 AM
2
Structured vs. Spaghetti programs
 Thirty five years ago, Edsger Dijkstra, followed by others,
made a powerful case against using control structures other
than the one-entry, one-exit blocks that came to be
known as "the control structures of structured
programming". They are, with a few complements, the
control structures of Eiffel: sequence (implicit most of the
time since you may omit the semicolon), if-then-else,
inspect, loop, routine.
 They are all one-entry, one-exit, meaning you can read
the code sequentially and don't have to turn yourself
into a computer and apply operational reasoning of the
style "if when executing this instruction I'm coming
from here it will satisfy this property, but if I am
coming from there it will satisfy that other property,
so in both cases ... it will be true that ... maybe ...
wait a minute... etc.
Department of Computer Science, York University
Slides based on Object Oriented Software Construction
2016-03-22 3:24 AM
3
Linear inspection of loops
 Some people view "break" and "continue" as milder forms
of the goto that do not raise the same problems.
 But in fact these forms are just as bad.
 Note in particular that what makes it possible really to
understand a loop is the notion of loop invariant: a
property that is ensured by the initialization, and maintained
by every iteration. The invariant is like an approximation
of the loop's goal (e.g. if we want to compute the maximum
of a structure -- the final goal -- the invariant states
that Result is the maximum *of the elements seen so far*).
Combined with the loop exit condition (in the example,
"we've now seen all elements") it allows the program reader
to check, through a simple inspection of the loop text,
that the loop is doing its job. The loop variant plays a
complementary role by telling us which decreasing quantity
guarantees that the loop will terminate.
Department of Computer Science, York University
Slides based on Object Oriented Software Construction
2016-03-22 3:24 AM
4
Reason statically not dynamically
 The key point is to be able to reason about a
program statically, i.e. by associating properties
with its text as given, rather than operationally,
i.e. by trying to mimic its execution within your
head.
 Computers are there to execute programs;
humans can't really do it effectively for any nontrivial examples. The one-entry, one-exit structure
helps us do something at which we are much
better: static reasoning based on the simple rules
of logic.
Department of Computer Science, York University
Slides based on Object Oriented Software Construction
2016-03-22 3:24 AM
5
Dijkstra
 In practice it is not surprising that if you have
been used to goto-prone languages you will find it
a bit hard at first to stick to the one-entry, oneexit discipline. I am sure that if you try earnestly
to overcome what initially seems like a hurdle you
will very quickly find that your programming style
improves, that the control structure of your
program becomes simpler, and that your programs
become more readable and maintainable.
 You can find Dijkstra's original paper at
http://www.acm.org/classics/oct95/
Department of Computer Science, York University
Slides based on Object Oriented Software Construction
2016-03-22 3:24 AM
6
C and Java
 It's too bad the designers of C and Java did not
heed its advice. I assume they had their reasons -probably they were afraid to lose programmers
who weren't ready to learn about structured
programming.
 In the case of Eiffel, the goal of helping people
write high-quality programs -- easy to debug, easy
to extend, easy to reuse -- was deemed more
important.
Department of Computer Science, York University
Slides based on Object Oriented Software Construction
2016-03-22 3:24 AM
7
Exceptions and rescue clauses


To make the discussion complete it's necessary to mention
that branching out of the innards of a control structure
*is* necessary in one special case: when you realize,
deep into the computation, that due to some unforeseen
condition you are unable to carry out the algorithm as
expected.
This is why there are exceptions. But in the
Eiffel approach exceptions don't function like goto
instructions: they trigger a different algorithm,
a "rescue" clause, which tries to patch things up
if at all possible. The rescue clause itself is a
one-entry, one-exit structure. (C++/Java exceptions
are also not gotos, but they are based on a different view.)
I hope that this clarifies the reasoning behind
Eiffel's control structures, and that you'll soon
stop regretting the absent "weapons" -- weapons of the
kind that too often turn back to hit those who
fired them.
With best regards,
-- Bertrand Meyer
Department of Computer Science, York University
Slides based on Object Oriented Software Construction
2016-03-22 3:24 AM
8
Error Removal & Code inspections
 Facts and Fallacies of SE, Robert Glass, 2003
 Fact 31: Error removal is the most time
consuming phase of the lifecycle
 Fact 37: Rigorous code inspections are the
closest we have to a silver bullet – inspections
can catch and remove 60-90% of errors.
 Despite this, code inspections are rarely used
(vendors don’t make money from it; gruelling
hard mind-intensive work)
 Is it easier to write or read programs?
 Current metric: 100 LOC/hour plus breaks
Department of Computer Science, York University
Slides based on Object Oriented Software Construction
2016-03-22 3:24 AM
9
Error Removal techniques
 Contracts
 Tests (automated ETester tests are very useful)
 Code inspections
 Both contracts and tests are also forms of
specifications.
 To do a good code inspection, you need a good
specification, which you need to check the
implementation.
 Structured programming significantly enhances
code comprehension and therefore code
inspections.
Department of Computer Science, York University
Slides based on Object Oriented Software Construction
2016-03-22 3:24 AM
10