Chapter 4 - Program Development
The past tutorials have dealt with some of the commands to use when programming. You could make programs
with what you have learned so far, but what is exactly involved in the design process? This chapter
deals with the design process and the general steps involved in the design process.
First steps
- What does the program do?
-
You must first determine what the program will do. Most of the time, this part is easy. If you are making a math program, for example, that solves the quadratic equation, you would want to know what the quadratic equation was, then! Knowing what you're going to do before you do it really helps!
- Can I do it?
-
You have to determine if you are able to write the program. That is, you have to know your limitations and the calculator's limitations. For example, if you've only read the past tutorials and that's all you know about Ti-83 programming, you probably wouldn't be able to make, say, a chess game. Not to say you couldn't try, but it would be extremely difficult and frustrating. You need more experience and knowledge. And even if you managed to make a chess game, you have to know the limits of the Ti-83, also. Is it going to be able to handle one player chess versus the calculator? Making computer AI to play chess is no simple task. Maybe it'd be better to make a Tic-Tac-Toe game! (Worry not, you'll have a chance to see some Tic-Tac-Toe action later on!).
- To 'pseudocode' or not to 'pseudocode'?
-
Pseudocode is done on writing down the design of a program before you actually start coding. The code you use for pseudocode isn't exact Ti-83 programming code, but it helps you define what the coding will be when you actually start coding on the calculator. It helps break down a program into blocks so you tackle the problem better. Pseudocode examples are given in the next section. Take note that pseudocode can be as defined or loose as you want it to be, as long as you have an idea at what you are going to. Also note that, while it may not be necessary to every program, having a general idea at what is to be done and where program flow will go is a good idea. Writing down these ideas (as pseudocode) is an even better idea if the program is too big too tackle in one sitting.
Program design
When making a program, it is a good to have an understanding of how to design a program. These steps are general breakdowns of what most programs are made of.
- Initialization/Setup
- The beginning of a program usually contains coding that initiatilizes and sets up the program, like clearing the screen and setting variables.
Pseudocode example:
Clear the screen
Set variables - $100->money
Ask user for name
- Menu Screen
-
- A menu screen at the beginning of a program is needed sometimes. For example, if you were making a Geometry program that solves for the area of various shapes, having a menu to control program flow into the different parts of the program is necessary. If the program was a simple program like finding circumference of a circle based on radius, having a start menu is unnecessary.
Pseudocode example:
Menu:
"Area-Solver"
1. Square
2. Rectangle
3. Circle
4. Ellipse
5. Triangle
6. About
7. Quit
Note that this pseudocode looks very similar to the actual menu screen instead of the actual coding of the menu. Writing down pseudocode like this (though some may argue that it isn't pseudocode) helps you visualize what a program is going to look like before running it!
- Main Loop
- The main loop of a program contains coding that will be active throughout most of the program. The main program code usually controls program flow and receives input.
Pseudocode:
repeat until user wants to quit program (str1 = "yes")
input "Quit program?", str1 <<<< if not yes, loop!
end repeat
- De-initialization
- De-initialization code is code that cleans up what your program did. For example, if you've created a list that is 99 elements long that was needed only during the program, you may want to delete it as part of your de-initialization code.
Pseudocode:
Delete L1 and L2 because they up over 700 bytes each!
Note: If you delete L1 - L6, it will no longer be available for viewing on the list edit menu. Simply hit [STAT] 5:SetUpEditor to have it created again (if need be) and lists 1 to 6 will all be available on the list edit screen again.
Speed versus Size versus Understandability versus Functionality
When programming, you sometimes have to weight out what type of coding you will implement (in fact, you always have to do this). It can be a task to find a balance between speed, size, understandability, and functionality. Take the following code:
ClrHome
Input "PASSWORD:",Str0
Lbl 1
If Str0="WHAT?"
Then
Pause "HOW DID'YA KNOW?"
Else
Pause "WRONG!!!"
Input "TRY AGAIN:",Str0
Goto 1
End
The same thing can be accomplished using the following code:
ClrHome
Input "PASSWORD:",Str0
While Str0!="WHAT?"
Pause "WRONG!!!"
Input "TRY AGAIN:",Str0
End
Pause "HOW DID'YA KNOW?"
(Note that != is the 'Not Equals' sign under [2nd] TEST 2:!=)
The second code is 11% smaller than the first one, but which one is easier to understand?
Beginners may use the first one, and it's understandable that one would code like that because
it is easy to understand, but others (more experienced, perhaps) may choose the second one because
overall you have to key in less and it has a "cleaner" look to it.
Even though these two programs
are trivial, if you had a game where you needed speed you would probably choose coding that takes up
less space, though it may be harder to understand, naturally you would have little problem
understanding your own coding, right? Basically, if you understand the code yourself that is the one
that you should choose, but as you gain more experience you'll tend to use smaller, faster, code
(and you'll wonder why people do it the "slow" way, also!). We'll tackle the subject of saving space
and revising code in later tutorials.