music

OSdata.com

if-then

summary

    This subchapter looks at if-then.

free computer programming text book project table of contents If you like the idea of this project, then please donate some money. more information on donating

stub section

    This subchapter is a stub section. It will be filled in with instructional material later. For now it serves the purpose of a place holder for the order of instruction.

    Professors are invited to give feedback on both the proposed contents and the propsed order of this text book. Send commentary to Milo, PO Box 1361, Tustin, California, 92781, USA.

if-then

    The IF-THEN structure is pretty straght forward. Your program tests to see if something is true. If the test is true, then your program does something (usually a sequence, although it can be any combination of the three control structures).

    For example, if you are tall enough, then you may go on the amusement park ride (which also implies that if you are not tall enough, then you can’t)..

    The thing being tested in an IF is called the condition.

    The two most common tests are for the condition to be TRUE or for the condition to be FALSE. Sometimes it is easier to write a program with a negative test (testing for a FALSE condition) rather than a positive test (testing for a TRUE condition). Sometimes it makes the program easier to read and understand (and therefore easier and less expensive to maintain over years or decades) for the test to be for a FALSE condition.

    While the basic control structure is testing for TRUE or FALSE, the test condition often can be for things slightly more complex conceptually, such as equality (are two thing sexactly equal), inequality (greater than or less than), length, time, emptiness, fullness, completion, incompletion, etc.

    Note also that we can have a simple test (only one condition is tested) or a compound test (multiple conditions are tested). Compound tests have potential problems in different programming languages, which will be discussed in detail when we get to the appropriate section.

    The THEN part is what is done if the condition passes (I’d say if the condition is true but you might have been testing for the condition to be false). The THEN part can be a single sequential step, a block (or group) of sequential steps, a block or group of any combination ot the three control structures, or a function or subroutine.

    After the test is completed and the action possibly taken, the program continues on to the next item in the sequence of steps. This is an important feature of structured programming: exactly one entry and exactly one exit. It is a disaster for maintenance if the program can start wandering all over the place.

    Using our average example, we might be interested in testing for zero divide before performing a division. Both elementary algebra and computer hardware reject any attempt to divide by zero (and the computer hardware can reject your attempt by freezing or otherwise crashing).

    In our sequence example for finding an average, we never actually stated where the numbers to be averaged came from. They just were there when we needed them. What would happen if we never received the input numbers? When we attempted to do the division of the subtotal by the count, the count could have still been zero. The program crashes.

    We could place a test for the count being zero just before we attempt to divide:

    IF count NOT EQUAL zero (0)
        THEN average = subtotal / count;

    This avoids the program crashing.

    We could also place a test for the existence of the numbers, somewhere near the start of the sequence (as one of the initialization steps). We would then place the entire rest of the block of sequential steps into the THEN portion, skipping the entire process if we don’t actually have our five input numbers. This approach would not only avoid a divide by zero crash, but also avoid wasting a bunch of computation time on something that is going to fail anyway.

Ada

PHP

Ruby

    The basic structure of a Ruby if statement is: the reserved word if, followed by the condition to be tested, optionally followed by either then or : (unless the entire statement is on a single line), folowed by one or more statements, and ending with the reserved word end.

    All three of the following examples have the same effect:

    if x == y then puts "successful test" end

    if x == y
        puts "successful test"
    end

    In Ruby it is also possible to use an if as a statement modifier. The following example has the same effect as the previous three examples:

    puts "successful test" if x == y

JOVIAL

    The following material is from the unclassified Computer Programming Manual for the JOVIAL (J73) Language, RADC-TR-81-143, Final Technical Report of June 1981.

    1.1.6 Flow of Control

    For structured flow of control, JOVIAL has an if-statement, a
    case-statement, and a loop-statement with an optional exit-
    statement.  Examples of these statements follow.

    Here is an example of an if-statement:

         IF SPEED < LIMIT;
            FLAG = TRUE;
         ELSE
            BEGIN
            FLAG = FALSE;
            VIOLATION = VIOLATION+1;
            End

    If SPEED is less than LIMIT, this statement sets FLAG to TRUE and
    does nothing else.  If SPEED is not less than LIMIT, the
    statement sets FLAG to FALSE and increments VIOLATION.  The last
    four lines of the example are a compound statement; the BEGIN-END
    pair groups the assignments to FLAG and VIOLATION into a single
    compound statement controlled by the ELSE clause.

    The ELSE clause of an if-statement is optional; when it is
    omitted, no action is taken when the condition is false.
    Furthermore, if-statements can be nested, so complicated control
    structures can be built up.  When if-statements get large and
    complicated, however, you can sometimes use a case-statement to
    clear thigns up.

    Chapter 1 Introduction, page 10

    Commentary: This example interestingly highlights the problem of writing about software without testing it. The author missed the fact that travelling exactly at the speed limit is actually permissible. The test should have been for less than or equal to rather than just less than. This is why you always test the software you write, including test cases at each limit.

---

free music player coding example

    Coding example: I am making heavily documented and explained open source code for a method to play music for free — almost any song, no subscription fees, no download costs, no advertisements, all completely legal. This is done by building a front-end to YouTube (which checks the copyright permissions for you).

    View music player in action: www.musicinpublic.com/.

    Create your own copy from the original source code/ (presented for learning programming).