title = {Structured programming with go to ... Dawn of structured programming ...
In C. – Duff's Device void copy(char *src, char *dst, int n) { switch (n & 3) {.
Structured Programming with goto Statements Yann-Gaël Guéhéneuc Article by Donald E. Knuth Presented in course IFT6310
GEODES Ptidej Team – OO Programs Quality Evaluation and Enhancement using Patterns Group of Open, Distributed Systems, Experimental Software Engineering Department of Informatics and Operations Research University of Montreal
© Guéhéneuc, 2008
Outline
Introduction Context Content – – – –
2/62
Introduction Elimination of goto Statements Introduction of goto Statements Conclusion
Discussions Map
Introduction Article
by Donal E. Knuth
– Published in 1974 in ACM Computing Surveys (since 1969!) – 41 pages (!)
3/62
@article{1241535, author = {D. Knuth}, title = {Structured programming with go to statements}, book = {Classics in software engineering}, year = {1979}, isbn = {0-917072-14-6}, pages = {257--321}, publisher = {Yourdon Press}, address = {Upper Saddle River, NJ, USA} }
Introduction Donald
4/62
E. Knuth (1938–)
– Professor Emeritus of the Art of Computer Programming at Stanford University – Author of The Art of Computer Programming – Creator of TeX and Metafont and “Computer Modern” typeface – Proponent of the Literate Programming philosophy of programming –…
Outline
Introduction Context Content – – – –
5/62
Introduction Elimination of goto Statements Introduction of goto Statements Conclusion
Discussions Map
Context Dawn
of structured programming Structured programming: one-in-oneout rule, where there is only one entrance into a structure, and only one exit out of the structure
Wonder 6/62
how it was before?
Context In
C
void copy(char *src, char *dst, int n) { while (n > 0) { *dst++ = *src++; n--; } }
7/62
Context In
C
– Duff’s Device
8/62
void copy(char *src, char *dst, int n) { switch (n & 3) { case 0: while (n > 0) { *dst++ = *src++; case 3: *dst++ = *src++; case 2: *dst++ = *src++; case 1: *dst++ = *src++; n -= 4; } } }
Context In
C
– Duff’s Device is legal in C – Duff’s Device is impossible in Java, which is more structured than C
9/62
using System;
Context In
public class SwitchGoto { public static void Main() { for(int i=1; i < 5; i++) { switch(i) { case 1: Console.WriteLine("In goto case 3; case 2: Console.WriteLine("In goto case 1; case 3: Console.WriteLine("In goto default; default: Console.WriteLine("In break; }
C# (!)
Console.WriteLine(); } } 10/62
}
case 1");
case 2");
case 3");
default");
Context In
Perl, excerpt from the documentation NAME SYNOPSIS DESCRIPTION NAME goto - create spaghetti code SYNOPSIS goto LABEL goto EXPR goto &NAME
11/62
Outline
Introduction Context Content – – – –
12/62
Introduction Elimination of goto Statements Introduction of goto Statements Conclusion
Discussions Map
Introduction Revolution
of structured programming
– Main concern: speed! – Related to: software crisis (circa. 1960) – Fear: restriction of the features in programming languages
13/62
Outline
Introduction Context Content – – – –
14/62
Introduction Elimination of goto Statements Introduction of goto Statements Conclusion
Discussions Map
Elimination of goto Statements Pros
– Removal of goto • Replaced by indentation • Replacing flow charts • Improved maintainability
15/62
Elimination of goto Statements Pros
– Introduction of for loops • Concealed loops 10 20 30 40 50 60
16/62
i = 0 i = i + 1 print i; " squared = "; i * i if i < 10 then goto 20 print "Program Completed." end for i = 1 to 10 print i; " squared = "; i * i next i print "Program Completed." end
Elimination of goto Statements Pros
– Improving “quality” • “the quality of their programmers was inversely proportional to the density of goto statements in their programs…” • Dijkstra’s article “Go to Statement Considered Harmful”
17/62
Elimination of goto Statements Edsger
Wybe Dijkstra (1930–2002)
– Recipient of the 1972 A. M. Turing Award – Schlumberger Centennial Chair of Computer Sciences at The University of Texas at Austin (from 1984 to 2000) – Fundamental contributions in the area of programming languages
18/62
• Shortest path-algorithm • Semaphore construct • Self-stabilization
Elimination of goto Statements ACM
A. M. Turing Award
– Alan M. Turing (1912–1954) • Turing Test • One of the first designs for a stored-program computer • Hut 8 at Bletchley Park (naval cryptanalysis)
19/62
Elimination of goto Statements ACM
20/62
A. M. Turing
Elimination of goto Statements Cons
– “We found that there was no way to implement certain simple constructions with while and conditional statements substituted for go to's, unless extra computation was specified” [bold mine]
21/62
Elimination of goto Statements Danger
– Unmaintainable “optimised” code • Optimise only the inner loops • Allow less efficient but more readable code in non-critical loops • “Premature optimisation is the root of all evil”
22/62
Elimination of goto Statements Error
exit
– “Sometimes it is necessary to exit from several levels of control, cutting across code that may even have been written by other programmers” Subscript
23/62
Checking Hash Coding Text Scanning Tree Searching
Elimination of goto Statements Replacement
Proposals
– Many proposals based on/by Kleene, Jacopini, Ashcroft… – “The underlying structure of the program is what counts” – Event Indicators – exit, jumpout, break, leave, loop…repeat
24/62
Outline
Introduction Context Content – – – –
25/62
Introduction Elimination of goto Statements Introduction of goto Statements Conclusion
Discussions Map
Introduction of goto Statements Pros
– Recursion elimination • Save space • Save time • Decrease clarity
26/62
Introduction of goto Statements Pros
– “Automatic” well-understood transformation
27/62
• Recursion elimination • Optimisations that a compiler cannot do • Removals of invariant sub-expressions from loops • Implementation of “abstract” data structure by “concrete” ones • Removals of Boolean variables by code duplication (!) • Co-routines
Introduction of goto Statements Pros
– Multi-way Branching • Micro-programmed emulator • Simulator
– “Fall-through”
28/62
Outline
Introduction Context Content – – – –
29/62
Introduction Elimination of goto Statements Introduction of goto Statements Conclusion
Discussions Map
Conclusion
“The act of focusing our mightiest intellectual resources on the elusive goal of go to-less programs has helped us get our minds off all those really tough and possibly unresolvable problems and issues with which today’s professional programmer would other have to grapple.” John Brown [Knuth citation: “In memoriam…”, unpublished note, January 1974]
30/62
Conclusion
“The real issues is structured programming” – Correctness proofs • Sufficiently convincing
– Different level of understanding (abstraction) – Clarity and understanding – “go to’s do not have a syntactic structure that the eye can grasp automatically” – “Better” language features – Efficiency – Agreed-upon language by… 1984 (!) 31/62
Outline
Introduction Context Content – – – –
32/62
Introduction Elimination of goto Statements Introduction of goto Statements Conclusion
Discussions Map
Discussions Old
debate… still on-going Compilation and compiler optimisations References to many still active fields of research in software engineering Writing Length 33/62
styles
Outline
Introduction Context Content – – – –
34/62
Introduction Elimination of goto Statements Introduction of goto Statements Conclusion
Discussions Map
Map
35/62
“to understand the associated mental processes more deeply” (p.261 left) “from a psychological standpoint to write […]” (p.278 left) “We understand complex things by systematically breaking them into successively simpler parts” (p.291 right) “to switch readily from microscopic to macroscopic views of things” (p.292 right) “the systematic use of abstraction” (p.292 right) “it is worthless as a level of abstraction” (p.293 left)
Models of program comprehension – Mayrhauser – Letovsky – Mayer
Map
36/62
“I argue for the elimination of go to’s in certain cases, and for their introduction in others” (p.262 right)
Dijkstra Dahl/Nygaard
Map
37/62
“as if the conceptual problems of programming could be resolved by a single trick” (p.262 right) “Sometimes it is necessary to exit from several levels of control” (p.269 left) “only if an exit from arbitrarily many levels of control is permitted” (p.277 right)
Programming language features Separation of concerns
Map
38/62
“software crisis” (p.263 left)
NATO 1968 Report
Map
39/62
“programming was supposed to be so easy” (p.263 left)
Steve Yegge’s Blog http://steveyegge.blogspot.com/ 2007/12/ codesworst-enemy.html
Map
40/62
“by 1984 we will see a consensus developing for a really good programming language” (p.263 right)
?
Map
41/62
“with a program using recursive procedures and Boolean variables” (p.264 right) “the transformation from recursion to iteration is one of the most fundamental concepts” (p.251 left)
Lisp-like languages
Map
42/62
“their observation that the quality of their programmers was inversely proportional to the density of goto statements” (p.265 left) “The underlying structure of the program is what counts, and we want only to avoid usages which somehow clutter up the program” (p.275 left)
Quality models
Map
43/62
“Our mistake was in assuming that there is no need for a label once the go to statement is remove” (p.265 right) “The underlying structure of the program is what counts, and we want only to avoid usages which somehow clutter up the program” (p.275 left)
Idioms Patterns Intermediate code Literate programming
Map
44/62
“most of the running time in non-IObound programs is concentrated in about 3% of the source text” (p.267 right)
Profiling
Map
45/62
“Premature optimisation is the root of all evil” (p.268 right) “and so do several other loop optimisations” (p.268 right)
“First make it work. Then make it right. Then make it fast.” by Kent Beck Agile methods
Map
46/62
“is like a sailor who wears his life preserver while training on land but leaves it behind when he sails!” (p.269 right)
assert keyword
Other checking mechanisms
Map
47/62
“Accompanying comments explain the program and relate it to the global structure” (p.272 right)
Flowcharts UML diagrams Frameworks
Map
48/62
“because we rely so much on comments which might possibly be inaccurate descriptions of what the program really does” (p.272 right)
“Good” identifiers “Good” comments
Map
49/62
“because the program is so beautifully symmetric between L and R” (p.273 right)
“Elegance”
Map
50/62
“but we’ve actually lost all the structure” (p.274 right) “If all identifiers in an ALGOL program were changed to random meaningless strings of symbols” (p.292 right)
Obfuscation and reverse-engineering
Map
51/62
“a way that we rarely think about go to statements” (p.275 right)
Introduction of OO programming OO programming features
Map
52/62
“the specification of events instead of labels encourages a better conception of the program” (p.278 left)
BCE method
Map
53/62
“One of the nice properties of his syntax is that the word repeat occurs naturally” (p.279 right)
Comparison of the syntax of programming languages
Map
54/62
“the compiler […] needs to know the properties of the data” (p.283 left) “correctness proofs and language semantics” (p.289 right)
Formal method and verification
Map
“programmanipulation system” (p.283 left)
55/62
Program transformations Refactorings Restructuring
Map
56/62
“Multiway branching is an important programming technique” (p.290 right)
Multi-methods
Map
57/62
“to create “logical spaghetti”” (p.291 left)
Anti-patterns Code smells
Map
58/62
“syntactic structure that the eye can readily assimilate” (p.292 right) “the eye can grasp automatically” (p.294 right)
Reading code Eye-tracking Visualisation
Map
59/62
“Building “integrated” products is an engineering principle” (p.295 left)
Product lines
Map
60/62
“automatically assemble integrated programs from wellstructured ones” (p.295 left)
Component-based programming
Map
61/62
“Engineering has two phases, structuring and integration” (p.295 left)
Software development processes
Map
62/62
“but almost invariably because their plan was poorly thought out” (p.296 left)
Plan-based programming
