Programming the Familiar

Discussion: Programming the Familiar
Good programmers are able to analyze a task and describe it succinctly, accurately, and unambiguously. Even tasks that you perform without much thought are surprisingly complex when you stop and consider all of their components. For example, using the self-checkout lane at a grocery storea simple task completed by thousands of people every dayrequires you to: (1) Select items in your basket; (2) Scan the UPC codes; (3) Convey the item to the bagging area; (4) Bag your groceries; and (5) Submit payment for your purchases.

A program is an ordered list of instructions that prepares the computer (or in the case of the grocery example, the shopper and new user of the self-checkout lane) to complete a task. Good instructions are mindful of the target audience, and the less you assume the reader already knows about a process, the more useful the instructions are to a wider audience.

If you have not used the self-checkout lane at a grocery store before, you act as your own cashier. You scan and weigh your items, bag them, and pay for them, while being guided by a digitized voice prompting you to complete each step.

Consider the pseudo code in the “Week 1 Discussion Code” text file (located in this week’s Learning Resources) that describes the self-checkout procedure. While it is comprehensive, it is also organized. It groups instructions related to the same task into a block of text, and adds comments and explanations using specific conventions:

Actions defined by a group of steps have descriptive names, including SelectItem, ScanBarCode, and PayingWithCredit.
Blocks of instruction are contained within braces: { and }.
// means that the rest of the line is a comment Intended for people, not an instruction to the computer.
When /* is used at the beginning of a line, it signifies that the entire line is a comment and will be ignored by the computer.
The symbols /** and */ start and end comments that extend over multiple lines. These are used to describe processes within your program.
Note: You will investigate this notation further in Week 2.

The code in the “Week 1 Discussion Code” text file (located in this weeks Learning Resources) includes line numbers along the left side of the page. These are not part of the program but they make it easy to refer to specific commands and instructions within the program.

Think about one task you perform so often, it is nearly automatic. Break that task down into its component parts and write a “program” that resembles the grocery self-checkout code provided to describe your task. Your task should include:

At least three major steps, listed in chronological order
Specific instructions that describe each step
Conditions that direct the flow of the program, such as “if-then,” “while,” or “until.”
Comments that explain your program
Line numbers
By Day 3
Post your program and read some of the programs posted by other colleagues. Identify steps in their programs that could be further developed to make the program unambiguous to as wide an audience as possible.

By Day 6
Respond to at least two other colleagues’ posts. Your responses should:

Identify a step or instruction in the program that could be further expanded or explained.
Explain why you think more detailed instructions would be valuable.
Write 510 lines of pseudo code that could be inserted into, or appended to the end of, the program to provide the additional instructions.