Talk:Structured programming

Untitled

Okay, that's good then. Note that it's quite possible to write structured code using just branch instructions. It's even provable I suppose. Guess what structured code gets compiled to? It's more important to show that your code has one point of entry and one point of exit. *But* the number one rule is still that your code should be readable. Structure, OO, etc. only helps you with this, it isn't the be all and end all of readability. (Unsure how to integrate this with what's already there though)

---

The paragraph on top-down design and programing is now wrong. The earlier version was not particularly well written, but it was more correct. Could someone who (A) knows, and (B) can write well, please fix this? (I don't want to; i wrote the earlier version and i don't want to get into an editing war.)

Opening Explanation

I think the opening paragraph is very weak. It starts off saying that "Structured Programming can be seen as..." and then goes to categorize the subject but avoids completely defining it. As you all know, the opening paragraph should provide a clear explanation to the layperson of what the overall idea of the subject is. Calling out to any experts on the subject! —Preceding unsigned comment added by BananaManCanDance (talk • contribs) 21:36, 30 September 2007 (UTC)

Missing something

Great, structured programming removes GOTO.... Ummm... that's not the point of structured programming, I hope ;-)

The idea is to make your code more readable and maintainable, and to help to divide and conquer your problem. Right? Sooo... that might need some rewording. Kim Bruning 18:03, 31 July 2005 (UTC)

Right. Sticking, for the moment with Dijkstra, "Structured Programming" means at least two things - what he was getting at, and the more limited notion that if you simply followed a few simple rules you would automatically create good programs. The quote gives, I think, the heart of his idea, "usefully structured" was what he said. The use, the end to which his approach was the means, was even more than readability, more like understandability, and better, belief by the reader that the code was correct. His position was that the programmer needed to "demonstrate its correctness in a convincing manner". He advocated "concatenation", "selection", and "repetition" as tools for achieving this end. AJim 00:27, 21 December 2005 (UTC)

Here is a fuller version of what he had to say about "useful structure". This is the crux of his argument.

3. On The Reliability Of Mechanisms
....
When we now take the position that it is not only the programmer's task to produce a correct program
but also to demonstrate its correctness in a convincing manner, 
then the above remarks have a profound influence on the programmer's activity: 
the object he has to produce must be usefully structured.

 …In what follows it will become apparent that program correctness is not my only concern, program adaptability or manageability will be another…

This quote was in an earlier version of the article, but has been edited out. I assume this is because some editors are more concerned with documenting the narrower concept of "Structured Programming" as a method, and less concerned with the point of "useful structure", which I take to be, first, making it possible to demonstrate the correctness of the program in a convincing manner, and, second, making it maintainable. It is important to note that when Hoare put the book, Structured Programming, together, it included not only Dijkstra's chapter, but a chapter Hoare wrote on Structured Data and a chapter by Dahl introducing what we now call Object Oriented Programming (all three authors, note, have received a Turing Award). That is, that the book was concerned with useful structure in the service of understanding, and not with a specific method of achieving it. To really grasp Dijkstra's point, I recommend reading the whole chapter, which, like most of the rest of the essay, remains relevant today, because it deals with fundamental issues, not with "silver bullet" methods. Which is not say that the method in the narrow sense is bad, far from it.

Especially relevant, and often forgotten, or never learned, is the corollary to the chapter's argument:

Program testing can be used to show the presence of bugs, but never to show their absence.

Or, as I was taught in another context, "You can't test-in quality."

One of the best arguments for useful structure, from Brian Kernighan, is a kind of joke, "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" --AJim (talk) 17:33, 21 June 2013 (UTC)

Who is Craig Davies?

(n/t) -- Kim Bruning 19:20, 4 April 2006 (UTC)

Knuth

I want --for myself-- to know the paper where Knuth proposed that "looser structural constraint.." If anyone knows? It could be written for references as well.Downtownee 13:07, 22 September 2006 (UTC)

This might be referring to Donald E. Knuth, Structured Programming with go to Statements
ACM Computing Surveys (CSUR) archive
Volume 6 , Issue 4 (December 1974) table of contents
Pages: 261 - 301
Year of Publication: 1974
ISSN:0360-0300
(Available at http://doi.acm.org/10.1145/356635.356640)
137.205.114.126 (talk) 15:38, 4 May 2010 (UTC)

Zebulon

"Although there is almost never a reason to have multiple points of entry to a subprogram" This does not sound right to me. Multiple entry points in a subprogram(or function or method, whatever you wish to call it) Is the very idea behind polymorphism, and polymorphism is a centeral tenant of OO programming. So it would seem to me is there are a great many reasons to have multiple entry points in a subprogram. Wednesday, November 15, 2006 6:28 AM (UTC)

I think the context has changed. An entry point into a subprogram is not the equivalent to a method call on an object.YAC (talk) 20:47, 13 August 2008 (UTC)

GOTO by another name

Recently while taking a C language course I saw the "break" and "continue" statements are these not GOTO by another name??? And really isn't the "else" a GOTO by another name??? Most "structured" computer languages have ways of exiting a loop in an abnormal fashion are not all of these (in whatever programming language) just another form of GOTO without the "sin" of using a GOTO??? Isn't any form of IF or SWITCH/CASE (and others) really a transfer of control = GOTO??? So all talk of 1 language being better because it doesn't have a GOTO is just so much propganda. Hardheadt 22:54, 12 December 2006 (UTC)

Years ago COBOL II, I think added 'Perform Thru'. COBOL Programs generatlly had pargarph names like 1000-DO-THIS. So you could perfrom 1000-DO-THIS thru 1000-DO-THIS-EXIT, for example. If you wanted to use 1000-DO-THIS-EXIT as a clean-up point you could write a lot of convulted code with deeply nested ifs (essentially useless), or you could use a GOTO. Some places actually wouldn't allow that simple because of the GOTO. Throwing an exception is equivalent to a GOTO - I've seen amazingly complex code written to avoid exiting a function in the begninning when the arguments were invalid - yet throwing an exception in the same conditions is de riquer. But, the good do-bees that follow all the rules would probably write crap if they didn't. The trick is to know how to use them as guidelines for writing good code rather than rules that require stilted code. YAC (talk) 17:44, 10 July 2008 (UTC)

Merge

Since this is defined merely in terms of unstructured programming being the converse of structured programming, it should really be part of the structured programming article. There isn't really a discipline of 'unstructured programming' as such, but as the article says, only people who should know better ;) —porges_(talk) 21:34, 14 July 2007 (UTC)

I have turned Unstructured programming into a redirect. I couldn't actually find anything there worth merging here; feel free to examine the old version in the history for yourself. --Csphdmoney 18:57, 5 August 2007 (UTC)

I've always liked "Stream of Consciousness", or "And Now Do This" programming. YAC (talk) 20:44, 13 August 2008 (UTC)

One derogatory name is "spaghetti code", that is, code where it is very difficult to follow the flow. Perhaps the epitomy of this is what a code obfuscator tries to do. Hard-to-understand code is pretty much the opposite of usefully structured code. There is an article on Obfuscation (software). --AJim (talk) 19:05, 14 August 2013 (UTC)

Obsolete?

Is discussion of structured programming still warranted? I wore out my Structured Prorgamming Books in the 80's and used the techniques into the 90's. But if OOP is available, discussing structured programming, other than as some kind of introduction to OOP - which I don't agree is necessary, seems like a waste of time. So why am I writing this? Good question. Painted myself in a corner it seems.YAC (talk) 20:51, 13 August 2008 (UTC)

And if functional programming takes over as the next programming fad, people will be asking the same thing about Oop. One could make it short and just agree with Ford in saying, "History is bunk." Or not. --217.132.200.209 (talk) 23:57, 19 December 2010 (UTC)

OR

While the origin of block-structured programming is easy to ref, e.g. [1], I can't find any book that uses the terminology "comb-structured programming". Pcap ping 13:35, 8 May 2010 (UTC)

Design

A one-sentence section? Really? - dcljr (talk) 09:13, 17 March 2011 (UTC)

What is a Reducible Flow Graph?

An quick explanation in the text would be nice. I found this "Characterizations of Reducible Flow Graphs" (1974 JACM)[[2]], but it isn't exactly simple for those not schooled in graph theory. Jimw338 (talk) 19:47, 21 April 2012 (UTC)

Wording

Graphical representations of the three basic patterns. The box diagrams (blue) were invented right for the new theory, and you can see here their equivalents in the mostly used control flow charts. This is the caption to the first image in the article, and it needs to be worded better, if not entirely re-written. Please fix it to be less Engrish.

-97.119.151.16 (talk) 22:28, 21 January 2013 (UTC)

To add to this: Where did this picture even come from? WHO invented these new box diagrams? Are the officially accepted by any organization? I've tried looking through Google Images, and can't find any program flowcharts that use these "new" box diagrams. It either needs a source, a better explanation, or deletion. 50.35.188.18 (talk) 20:38, 7 January 2014 (UTC)

Logical and physical structuring

When discussing Structured Programming people often get logical and physical structuring confused. Structured Programming describes logical structuring of systems and programs. The "Low-level structured programming" section of this article describes physical structuring and is therefore entirely irrelevant to Structured Programming. This article should emphasize logical structuring and should emphasize that Structured Programming is not about physical structuring. Sam Tomato (talk) 02:28, 27 November 2013 (UTC)

External links modified (January 2018)

Hello fellow Wikipedians,

I have just modified one external link on Structured programming. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20131023061601/http://cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoTo.pdf to http://cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoTo.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 23:33, 21 January 2018 (UTC)

Confusion over "single-exit" principle

This article pretends that "single-exit" means single return statement, while apparently this is not at all what it means. See flowcharts in "Notes on Structured Programming" by Dijkstra, and here is a quote:

These flowcharts share the property that they have a single entry at the top and a single exit at the bottom: as indicated by the dotte block they can again be interpreted (by disregarding what is inside the dotted lines) as a single action in a sequential computation.

So, "single-entry, single-exit" means that from the outside, the "block" should look like a single piece, with one entry and one exit. It does not matter whether inside the block there are multiple return statements -- it does not change the external look/interface of the block.

In the context of functions, "single-exit" just means that the function returns to where it was called from -- it cannot decide to return elsewhere (no continuation-passing style?).

See this answer on SoftwareEngineering.SE. --Alexey Muranov (talk) 12:30, 16 February 2020 (UTC)

mathematics

area of a triangle 105.160.110.227 (talk) 14:56, 28 August 2022 (UTC)

Structure paradigm

Discussion 2001:4455:232:A400:A04A:3FD1:7AEA:B7F1 (talk) 14:06, 11 October 2022 (UTC)

Programing c

Explain programing structure 2402:3A80:1348:297:98AF:E807:C1B3:FA8D (talk) 07:34, 8 November 2022 (UTC)

What does Donald Knuth really say?

I have a question about the "History. Debate" section where it is said about Knuth paper "Structured Programming with Goto Statements."

The article "Structured Programming" says: "Knuth proposed a looser structural constraint: It should be possible to draw a program's flow chart with all forward branches on the left, all backward branches on the right, and no branches crossing each other."

Sorry, but I couldn’t find in the Knuth’s paper such phrase. There is no such phrase in the Knuth’s paper. In Wikipedia this phrase should be eliminated.

May be I am mistaken. Please, tell me, what is my mistake? I shall be very obliged if somebody be so kind to help me and show me exact place in the Knuth’s paper where is the phrase needed hidden.

Here is the link to Knuth paper: Knuth D. Structured programming with go to statements

Владимир Паронджанов (talk) 08:43, 29 October 2024 (UTC)