Department of Computer Science, York University Slides based on Object Oriented Software Construction 16/10/2015 4:08 PM 0 COSC3311 – Software Design Gotos, Breaks and Structured Programming

Department of Computer Science, York University Slides based on Object Oriented Software Construction 16/10/2015 4:08 PM 1 What’s wrong with `break’ | | Subject: AT& T Bug | | Date: Fri Jan 19 12: 18: | | | 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 long- distance 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 16/10/2015 4:08 PM 2 Statement from Bertrand Meyer  (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 16/10/2015 4:08 PM 3 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 16/10/2015 4:08 PM 4 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 16/10/2015 4:08 PM 5 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 non- trivial 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 16/10/2015 4:08 PM 6 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, one- exit 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

Department of Computer Science, York University Slides based on Object Oriented Software Construction 16/10/2015 4:08 PM 7 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 16/10/2015 4:08 PM 8 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 16/10/2015 4:08 PM 9 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 16/10/2015 4:08 PM 10 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.