Talk:Computer Programming/Control

Other languages

When changing inside the Computer Programming/Control do have a look how your change will affect the other languages - you don't have to fix them - but do consider them.

--Krischik 08:32, 17 Apr 2005 (UTC)

Subroutines & Subprograms

I program a lot in RPG which uses Subroutines & Subprograms which can be like functions. There are work variables associated with the subroutine or subprogram ... feed the info in, call it, when it is done it returns the answers. Thus we develop standard routines to do standard functions which can be used as building blocks for many different programs. Is this considered to be part of Control Statements, or another element of programming? AlMac 09:08, 16 July 2005 (UTC)

Procedures and functions

I guess the proper place would be Computer Programming/Procedures and functions. The X dependency should be removed and replaced by a language independent definition.

--Krischik 06:08, 18 July 2005 (UTC)

Evil Goto by scenario

Perhaps there should be a separate article on the pros & cons of GOTO and perhaps I should write some of it.

When accepting complex input, we can avoid GOTO using cumbersome code like this

1. Start Point of setting up variables
2. Populate variables associated with starting point of the data to be read
3. Clear flags or variables used to track whether input will be Ok, that are neccessary to manage the loop
4. Define the loop such that we fall out if after all the rigamarole, there are no problems.
5. Start Point of loop
6. Give screen to user to supply data, or access file or whatever
7. Get the data
8. Analyse the data
9. If whatever problem, put error message into relevant variable, or reset so as to read next record in file.
10. Also set flag indicating problem requiring return to start point of loop
11. Conditions of loop either mean we fall out, or return to Start Point of loop
12. Now that we have good data we can process it

Or we can have much easier to read code with GOTO.

1. Start Point of setting up variables
2. Populate variables associated with starting point of the data to be read
3. Start Point of loop
4. Give screen to user to supply data, or access file or whatever
5. Get the data
6. Analyse the data
7. If whatever problem, put error message into relevant variable, or reset so as to read next record in file.
8. GOTO Start Point
9. Now that we have good data we can process it

AlMac 09:02, 16 July 2005 (UTC)

The algorithm using GOTO has some problems:

• The GOTO target 'Start Point' is not defined. There is a 'Start Point of setting up variables' and a 'Start Point of loop', which one do you mean?
• It describes an endless loop, as there seems to be no conditional. In other words, replace the unconditional GOTO by this step: 'Conditions of loop either mean we fall out, or return to Start Point of loop (via GOTO)'
• This step is missing: 'Clear flags or variables used to track whether input will be Ok, that are necessary to manage the loop'
• This step is missing: 'Also set flag indicating problem requiring return to start point of loop'

The description of the algorithm without GOTO mentions the same functionality twice:

• Define the loop such that we fall out if after all the rigamarole, there are no problems.
• Conditions of loop either mean we fall out, or return to Start Point of loop

Also,

• prefer to simplify the discussion by combining all initialization steps (common to both algos) into a single step.
• Similarly, combine all loop body steps (common to both algos) into a single step.

If these points are fixed, both algorithms are of the same subjective complexity.

Rainer

Non-local exit considered harmful

"Because the use of a goto needs the declaration of a label, the goto is in fact as twice as readable than the use of return. So if readability is your concern and not a strict "don't use goto" programming rule then you should rather use goto than multiple returns. Best, of course, is the structured approach where neither goto nor multiple returns are needed:"

It's odd to see such an old chestnut from the Structured Programming Wars resurface. The fact is that non-local exits are sometimes bad, and sometimes preferable to a morass of if-elses. Consider a C-like language with no exception constructs:

        int widgetcontainer_add(container c, widget w) {
            if (w == null) return ERR_NULL_POINTER;
            if (w.chroma < colors.green) return ERR_OFF_COLOR_WIDGET;
            if (c.count >= c.capacity) return ERR_CONTAINER_FULL;

            c.items[c.front++] = w;
            return OK;
        }

The solution here, of course, is "use exceptions, not error codes", but failing that, multiple returns are a lot more readable than the structured alternative:

        int widgetcontainer_add(container c, widget w) {
            int result = OK;
            if (w == null) {
                result = ERR_NULL_POINTER;
            } else if (w.chroma < colors.green) {
                result = ERR_OFF_COLOR_WIDGET;
            } else if (c.count >= c.capacity) {
                result = ERR_CONTAINER_FULL;
            } else {
                c.items[c.front++] = w;
            }
            return result;
        }

Here the nature of the checks is completely obscured, as is the "real code", which is just the last in a long line of alternatives. The reason people promote such code anyway is not readability, but consistency of form, which is actually much of what structured programming is about.

The idea behind restricting (or forbidding) non-local exits is that as the function grows longer, the control flow gets more and more unclear if there are multiple points of exit ("If parameter x is 5, did we exit here or here or here? Does this piece of code ever get executed?") The "non-structured" answer to this is simply not to use big functions (or methods/blocks/closures/whatever), since they are much more problematic than the control structures you use within functions will ever be.

A bigger straw man here is claiming that the version with goto is in fact "twice as readable" because a label is involved. Say what? Is the reader supposed to glance over a "return" statement, or something, or forget that "return" exits the function? I don't know what the author was thinking here. 82.92.119.11 22:14, 8 June 2006 (UTC)