[Home]Structured programming

HomePage | Recent Changes | Preferences

Difference (from prior major revision) (minor diff, author diff)

Changed: 3c3
It is possible to do structured programming in almost any procedural programming language, but since about 1970 when structured programming began to gain popularity as a methodology, most new procedural programming languages have included features to encourage structured programming, (and sometimes have left out features that would make unstructured programming easy). Some of the better known structured programming languages are
It is possible to do structured programming in almost any procedural programming language, but since about 1970 when structured programming began to gain popularity as a methodology, most new procedural programming languages have included features to encourage structured programming, (and sometimes have left out features that would make unstructured programming easy). Some of the better known structured programming languages are

Removed: 8d7


Changed: 14c13,15
For larger pieces of code, the use of subroutines (functions and procedures in some languages) is encouraged, and it is recommended that each subroutine should be small enough to be understood easily. Use of variables local to the subroutine, and also use of parameters, is highly encouraged, while excessive use of global variables is frowned on. All this is to make it easier to understand small pieces of code in isolation, without having to understand the whole program at once.
Coders should break larger pieces of code into shorter subroutines (functions and procedures in some languages) that are small enough to be understood easily.
In general, programs should use global variables sparingly; instead, subroutines should use local variables and take arguments by either value or reference.
These techniques help to make isolated small pieces of code easier to understand without having to understand the whole program at once.

Changed: 16c17
Structured programming is often (but not always) associated with a "top-down" approach to both design and programming. In this way the large scale structure of a program is designed and implemented first, in terms of smaller operations that will be fully designed and implemented later.
Structured programming is often (but not always) associated with a ["top-down" approach to design]?. In this way designers map out the large scale structure of a program in terms of smaller operations, implement and test the smaller operations, and then tie them together into a whole program.

Changed: 18c19,21
By the end of the 20th century, structured programming was endorsed by the vast majority of serious programmers using the procedural programming paradigm. The main benefit claimed is that structured programs are supposed to be easier to understand, leading to improved reliability and easier maintenance. Attempts to actually measure this have been rare, and there is a suspicion in some circles that the benefits are real but small.
By the end of the 20th century, the vast majority of serious programmers endorsed structured procedural programming.
They claim that a fellow can understand a structured program more easily, leading to improved reliability and easier maintenance.
Attempts to actually measure this have been rare, and there is a suspicion in some circles that the benefits are real but small.

Changed: 20c23,24
Towards the end of the 20th century, there have been serious attempts at paradigms that are loosely based on proceedural programming, and accept the lessons of structured programming, but attempt to go beyond this in providing structure for data as well as for program flow. Object-oriented programming in most cases can be seen as an example of this, although there are also some object-oriented variants that are not procedural.
Towards the end of the 20th century, designers have created new paradigms loosely based on procedural programming that accept the lessons of structured programming but attempt to go beyond this in providing structure for data as well as for program flow.
Object-oriented programming in most cases can be seen as an example of this, although there are also some object-oriented variants that are not procedural.

Changed: 22c26,27
Structured programming languages provide constructs for creating a variety of loops and conditional branches of execution. Unstructured languages provide a method of creating a label in code and a GOTO command.
Unstructured languages define control flow largely in terms of a GOTO command that transfers execution to a label in code.
Structured programming languages provide constructs (often called "if-then-else", "unless", "while", "until", and "for") for creating a variety of loops and conditional branches of execution, although they may also provide a GOTO to reduce excessive nesting of cascades of "if" structures, especially for handling exceptional conditions.

Changed: 24c29,30
Strictly speaking, in a structured programming language, any code structure should have only one entry point and one point of exit; but, in many programming languages, such as C, it is possible to create multiple exit points.
Strictly speaking, in a structured programming language, any code structure should have only one entry point and one point of exit;
many languages such as C allow multiple paths to a structure's exit (such as "continue", "break", and "return"), which can bring advantages in readability.

Structured programming can be seen as a subset or subdiscipline of Procedural programming, one of the major paradigms (and probably the most popular one) for programming computers.

It is possible to do structured programming in almost any procedural programming language, but since about 1970 when structured programming began to gain popularity as a methodology, most new procedural programming languages have included features to encourage structured programming, (and sometimes have left out features that would make unstructured programming easy). Some of the better known structured programming languages are

At the level of relatively small pieces of code, structured programming typically recommends simple, hierarchical program flow structures. These can be obtained in most modern languages by using only structured looping constructs, often named "while", "repeat", "for". Often it is recommended that each loop should only have one entry point and one exit point, and a few languages enforce this.

Alternative thinking on structured loops exists. Donald Knuth has advocated flow graphs that can be written with all forward branches drawn to the left of the code, all backward branches drawn to the right, and no branches crossing each other in this representation. Those knowlegeable in compilers and graph theory have advocated allowing only reduceable flow graphs.

Coders should break larger pieces of code into shorter subroutines (functions and procedures in some languages) that are small enough to be understood easily. In general, programs should use global variables sparingly; instead, subroutines should use local variables and take arguments by either value or reference. These techniques help to make isolated small pieces of code easier to understand without having to understand the whole program at once.

Structured programming is often (but not always) associated with a ["top-down" approach to design]?. In this way designers map out the large scale structure of a program in terms of smaller operations, implement and test the smaller operations, and then tie them together into a whole program.

By the end of the 20th century, the vast majority of serious programmers endorsed structured procedural programming. They claim that a fellow can understand a structured program more easily, leading to improved reliability and easier maintenance. Attempts to actually measure this have been rare, and there is a suspicion in some circles that the benefits are real but small.

Towards the end of the 20th century, designers have created new paradigms loosely based on procedural programming that accept the lessons of structured programming but attempt to go beyond this in providing structure for data as well as for program flow. Object-oriented programming in most cases can be seen as an example of this, although there are also some object-oriented variants that are not procedural.

Unstructured languages define control flow largely in terms of a GOTO command that transfers execution to a label in code. Structured programming languages provide constructs (often called "if-then-else", "unless", "while", "until", and "for") for creating a variety of loops and conditional branches of execution, although they may also provide a GOTO to reduce excessive nesting of cascades of "if" structures, especially for handling exceptional conditions.

Strictly speaking, in a structured programming language, any code structure should have only one entry point and one point of exit; many languages such as C allow multiple paths to a structure's exit (such as "continue", "break", and "return"), which can bring advantages in readability.

/Talk


HomePage | Recent Changes | Preferences
This page is read-only | View other revisions
Last edited November 10, 2001 1:53 pm by 203.37.81.xxx (diff)
Search: