Tackling any task can be challenging, and invariably the hardest part is the first step: Where do I begin? At this stage your biggest obstacle is ignorance, a rather undaunting obstacle to overcome!! So, to begin you must break down your task into smaller problems, by replacing the question Where do I begin?, with four questions which will define the way you attack your problem:
I encourage you to take a look at Bruce Molay's Understanding Unix/Linux Programming where he implements this philosophy. The first of the three questions are introduced in section 1.3.3 (p. 7) and the final question in section 2.6.4 (p. 55). I will consider each question below.
Your first hurdle is the problem of circumscribing exactly what your task is. If your lucky someone else has completely solved this problem, but invariably you will need to give some thought here. The primary point to remember is that you do not want to overburden the rest of your effort by trying to do too much too soon. This is the reason that I introduced the fourth question above: How can I make my solution better? What is the minimum your program will need to do, to solve the task? You may need to simplify this problem further, by setting a more modest goal, then build from there. At this stage there are three questions you will want to address:
This final question will probably be rather difficult to answer at this stage, but it is good to think about the ways a program can go wrong:
The aim at this stage is to work through the logic of your program. What steps will your program have to take between its recieving the input values and its returning the output values? What is the order that they must be performed?:
Your goal at this stage is to conceptually simplify your task, by breaking it down into subtasks. You should not be concerned that what is conceptually simple may be rather difficult to program; later, when you address the question Can I get the computer to do this? you may need to come back and answer the question for this new task.
Once you have broken down your one task into several, you need to determine the correct order to perform each task. If you have had Algorithms, you might think of this stage as preparing pseudocode; but even a flow diagram is sufficient. You will find a couple of examples from Mollay's book on pages 20 (for more) and 48 (for who).
You now have a template for your program. At this point, I open up my text editor and type in my template (if your program is in C, you can add the main function, or any other opening statements that are required.) You are ready to program!!
Now that you have a template, you can fill it out with your program. A fatal mistake is to try to fill in your program, then debug it. Use your template wisely. It is both a guide for your code, and a guide for your testing. If you are like me, you will spend more time debugging code then researching and writing it. Debugging is greatly simplified when the code that requires it is smaller. With this in mind, there are three steps to filling in you template:
You have many resources available to you for researching the functions the language places at your disposal. What you should keep in mind is the particular task you want to perform. Unfortunately, many functions pack in alot of functionality which is not going to be required. Do not bog down on details that you do not need. But make sure you have all the details you do need!!! For each function that may be of value I make a table of relevant information:
| Function Name | |
| Purpose | What the Function does which is relevant to your task |
| Include | Header files you will need |
| Usage | Function prototype (the function's syntax) |
| Arguments | The appropriate range of values for each argument (at least include those values which are appropriate to your task) |
| ReturnValue | Function's return value (pay special care to note the return value on error) |
| Errors | The possible causes of errors (this is closely related to the range of acceptable values for each argument) |
The purpose of this table is not to include everything the function does, but only what is relevant to your task. This means that what you need under Purpose, Arguments, ReturnValue, and Errors should be limited to what you expect to need. You will find an example of this style in Mollay's book (for example, p. 41 for open.)
I recommend you write the code for each task and test that code separately. It will be simpler to debug your code; but it also serves the purpose that you can play with unfamiliar functions. It will also give you some extra time to think about your code, and may lead to ways of simplifying the code you write. You should also be aware that your template may not be as finely detailed as will be useful. Often a conceptually simple task requires a bit of code to perform. You may need to re-ask How can it get done?.
By this stage you have a working program, but it might not do everything that is required of it (especially, if you simplified your task when answering What do I need to do to complete this task?.) Even if your program does everything you set out to do, since you have been thinking hard about your task, you probably have come upon ways of extending your program. Don't stop short. This is where the real fun begins!!!