There are two ways to write a computer program: The right way and the wrong way.
If you program the right way you will be successful, get a
great job, marry rich, and live a long and healthy life.
If you program the wrong way your life will filled with misfortune and failure,
you will be scorned by family and friends, you will be sickly and your life will
be short and painful.
No matter what type of program you are writing, what you are really doing is
solving a problem.
You must attack the problem in a logical and structured way.
Computer programming is very similar to solving an algebraic word problem (two
trains leaving Chicago…). You can't solve it until you turn it into a numeric
algebra problem. The same is true of a computer program. The computer
doesn't understand what a train is or what a "Chicago" is ;-).
The word problem must be translated into something that you can understand.
If you don't understand the problem then you'll never get the computer to
understand it.
The process of solving the problem requires certain steps to be taken….don’t
skip steps Ever!!!!!!
First Step: The Problem Statement.
1. Define the scope of the problem by specifying all assumptions.
2. Spell out what data needs to be input into our
program
3. Determine which calculations need to be made
4. Write down what the end product will be (what will we have when the problem is
solved). In most cases it will be an Output of information.
Let's try something fairly simple:
You have been tasked with writing a computer program that will get a product cost and return the recommended sale price for that item based up our standard markup of 40%.
When we display the problem statement we display it like this:
1. Assumptions:
2. Input
3. Calculations:
4. Output
That is not the most efficient order to solve the problem though. The reason why we display it that way is because when we write the program it will normally start with input, then you'll do some calculations and end with output. When we breakdown the paragraph into these parts though we do it in this order: Output, Input, Calculations, Assumptions
4. Output: What is it that our program must
produce? In this case the output will be the Sales Price.
3. Calculations: To come up with the output of sales price,
what calculations must we perform? In this case we must do the following:
Sales price = Cost * 1.40 (notice this seems backwards. In programming we
write equations this way (what we are looking for = the calculation necessary to
get what we are looking for).
2. Input: What must be input into our program in order for us
to do the above calculation? We definitely need the cost, but what about
the Markup number (40%)? Is that input into our program? If we get this
part wrong then all the work we do from this point forward is wasted. We
need to read the paragraph and figure this out. The paragraph says that
the markup is based upon the standard markup of 40%. That means that the
markup is constant. We will be writing it into our code. If they
said, "the standard markup is 40% but that can change. Well, if it can
change then we will want someone inputting the current markup. Since the
markup in this problem is standard and does not change then it will not be classified as input.
Input is what a user of our program will be typing in. We, as the
programmer will be typing the 1.40 multiplier into our code so it is NOT input.
A good example is sales tax when you check out at Walmart. The cashier
doesn't ask you what the sales tax is nor do they type it in during each sale.
The sales tax rate is in the code running on the cash register. All the
cashier inputs are the bar codes of the stuff you are buying. Our program
will be the same way. We will ask for the item cost but not what the markup
percentage will be, that will be part of our calculation.
1. Assumptions: This is the "catch all" section. We
document other important facts that are not documented in the other three.
What assumptions can we make from this simple problem.
a. Markup is 40%
b. Only one price will be analyzed at a time.
In the correct order our problem statement would look like this:
1. Assumptions:
a. Markup = 1.40
b. Only one price will be analyzed at a time
2. Input: Cost of Item
3. Calculations: Sales Price = Cost of Item * Markup
4. Output: The Sales price is [Sales Price]
Why the problem statement is the most important step as a
programmer!
If you are already doing some programming it is probably personal
programming. Writing programs for yourself whether for a desktop
application or most likely, a internet application. When you are
programming for yourself this step isn't as important as when you are
programming in a professional environment.
In a professional environment you will be writing a program in support of another organization in your company or perhaps writing an Internet application for a client. Since you are being paid by someone else to do the coding (thus making you a professional) you need to be sure what you are coding is exactly what is necessary to solve the problem. Here's how it works:
1. You meet with a client and get the requirements. The client will have little idea of what you can do or even what they want but want you to solve their problem. This is particularly difficult because your client (the only place you can get information) is usually clueless and would rather not talk to you at all. Your job is to get all the information you can force from the client (I have found that numerous head slaps loosen their tongues). Then you need to leave them and write up a problem statement based upon what they told you.
2. Although neither of you want to talk to each other, you meet with your client for a second time and go over the problem statement to ensure that you have outlined the problem correctly. Since you have neatly and logically outline exactly what must be done they will be able to verify that you have correctly defined the problem and the solution to that problem. Once you have that "meeting of the minds" have them sign the completed problem statement so that later on they can not lie and say "that's not what I told you I wanted".
3. After you have completed the program requirements via the problem statement. You will then create a list of steps that must be taken in order for the problem to be solved and the program to work. I call this the "human algorithm" because it is the steps you would take if you were doing this without the computer. Why must you do this? Well, if you can not solve the problem on paper you will not be able to solve it with the computer. The steps need to be very simple and only have one task on each line. I like to say that you are writing instructions for your idiot cousin to follow when you go to lunch. I do this to emphasize that each line must be simple.
This is our Human Algorithm*:
1. Markup = .40 <-- Assigning 40% to Markup
**
2. Ask for the cost of the item.
<-- Input
3. Calculate the Sales Price by multiplying the Cost by
the markup <--Calculation
4. Display: The sales price is [Sales Price]
<-- Output
5. Program Ends (you don't need to write the step)
* Notice out our human Algorithm is in the same order as our
Assumptions, Input, calculations, output sections of our problem statement. You will
see that a lot as we go along.
** Step 1. Assigning 40% to markup is important. Whenever we state a
"constant" which is a number that will not change when we run our code, in our
assumptions, we need to make those assignments as the first steps in our human
algorithm. 2. only one price at a time does not assign a value so it is
not part of our human algorithm.
4. Desk Check your human algorithm. You desk check
it by using example numbers to see if you come up with the correct answer.
This way if you are missing a step you'll find out now.
1. Assignment .40 as our markup
2. Ask for the cost of the item: $10
3. Calculate the Sales Price: $10 * Markup (1.40) = $14.00
4. Display: The Sales Price is $14.00
5. After we have created our human algorithm and desk checked it for accuracy we need to create a pictorial of our human algorithm so we can visual check to ensure it works. With such a small program as this it seems silly to go through all this but it's important that you hone your skills on easy programs so you can apply these skills to more complicated problems later on. The pictorial we will be creating is called a flowchart. We use specific symbols to represent different actions in our program. Parallelograms represent input and output whereas a rectangle represents a calculation. This is our flowchart for this problem.
As you can see above: Assignment, Input, then a calculation, then an output.
That's it! So that's another benefit of the flow chart. Where ever we have an input symbol or a calculation symbol you will need to have a place in memory to store the data that's input (item cost) and the result of the calculation (sales price)
6. The last thing we do is start coding our problem. It is a good idea to meet with your client after each step and go over that step with them so they can, once again, verify that this is exactly what they want. You will notice after the first line of code we type "option explicit". You need to do that in every script you type. Option Explicit tells the VB interpreter that we will only be using the places in memory declared on the DIM line. That way if we make a typo it won't create a brand new place in memory. Be sure to automatically type that as your second line of code for each program you create. Here's our code:
<Script Language = "VBScript">
Option Explicit
DIM ItemCost, SalesPrice, markup
'<-- places in memory
markup = 1.40
ItemCost = Inputbox("What is the cost?") '<-- Input
SalesPrice = ItemCost * markup
'<-- Calculation
Document.write "The Sales Price is " & SalesPrice '<-- Output
</Script>
You can see that every line of code comes from our setting up places in memory or a symbol on our flowchart. If you do the steps in order you'll never have a problem coding since you have already solved the problem in the first 5 steps. You will also notice that each symbol in our flowchart comes from each line of our human algorithm and each line of code comes from each symbol of our flowchart. That's why we do the step by step process, it makes your final product fool proof.
Unfortunately, each semester a group of students feel that this process is too time consuming and try to write the code first then work backwards through the flowchart then problem statement. Well, they are successful in the first few easy programs but then when the programs get more complex they can not do it backwards and they haven't really learned to the it the correct way. As I mentioned in the top of this tutorial they end up very unhappy and usually can not complete the class. Don't let this be you!!!!