The Programming Process
All programming involves creating something that solves a problem. The problems can range from something of great scientific or national importance, through to something as trivial as relieving personal boredom!
This section describes one approach to solving such problems - think of it as a rough guide to the things you should do when entering the land of programming.
In broad terms, those things are:
Of these, only the third step is usually called "programming", but as you'll see later, it's probably the least important stage of the process.
Identify the Problem
In fact, this stage should really be called identifying the solution because what you're really trying to do is to tie down exactly what it is that you're trying achieve.
There are two stages to identifying a solution:
The first step is to examine the problem carefully to try to identify what qualifies as a solution. A single problem may have many different solutions, but they will all have something in common. So here you're trying to work out exactly what your program will be required to do.
The second step is to then look at the list of requirements and to decide exactly what your solution should do to fulfil them. As we mentioned above, there are usually many different solutions to a single problem; here, your aim is to decide on which of those solutions you want. Therefore, you're trying to specify, in a fairly accurate manner, just what it is your final program will do.
By the time you have worked out your specification, you should have a very clear idea of what your final program will do: your goal.
Design a Solution
Once you've identified the things required to solve your problem, and specified what form your solution will take, the next step is to work out just how you're going to turn that specification into a working program. This is usually the hardest task!
As mentioned before, a program is simply a list of steps describing to the computer what it should do. A design is simply a higher-level description of those steps. In effect it's a program written as if the computer was a person. So, it doesn't have to completely spell out every step - because humans know how to do a lot of things already and have a lot of common sense, meaning that they can work the simple steps out for themselves. It also doesn't have to be written in any special programming language - English will do (although people often use special notations like pseudocode or flow charts for the more complicated sections).
Another way of looking at is that a programmer should be able to take a design and write the program from it without having to think too hard. It's a bit like an architect's drawing: it contains all the important structures without showing every bit of brick and mortar.
Working out a design to fulfil a particular specification can be difficult for several reasons:
We'll return to these problems a bit later on in the course.
When your design is completed you should have a very clear idea of how the computer is going to fulfil your specification, which in turn meets your requirements, which in turn should solve your original problem.
Programming is then the task of describing your design to the computer: teaching it your way of solving the problem.
There are usually three stages to writing a program:
Coding is the act of translating the design into an actual program, written in some form of programming language. This is the step where you actually have to sit down at the computer and type!
Coding is a little bit like writing an essay (but don't let that put you off). In most cases you write your program using something a bit like a word processor. And, like essays, there are certain things that you always need to to include in your program (a bit like titles, contents pages, introductions, references etc.). But we'll come on to them later.
When you've finished translating your design into a program (usually filling in lots of details in the process) you need to submit it to the computer to see what it makes of it.
Compilation is actually the process of turning the program written in some programming language into the instructions made up of 0's and 1's that the computer can actually follow. This is necessary because the chip that makes your computer work only understands binary machine code - something that most humans would have a great deal of trouble using since it looks something like:
01110110 01101101 10101111 00110000 00010101
Early programmers actually used to write their programs in that sort of a style - but luckily they soon learnt how to create programs that could take something written in a more understandable language and translate it into this gobbledy gook. These programs are called compilers and you can think of them simply as translators that can read a programming language, translate it and write out the corresponding machine code.
Compilers are notoriously pedantic though - if you don't write very correct programs, they will complain. Think of them as the strictest sort of English teacher, who picks you up on every single missing comma, misplaced apostrophe and grammatical error.
This is where debugging makes it first appearance, since once the compiler has looked at your program it is likely to come back to you with a list of mistakes as long as your arm. Don't worry though, as this is perfectly normal - even the most experienced programmers make blunders.
Debugging is simply the task of looking at the original program, identifying the mistakes, correcting the code and recompiling it. This cycle of code -> compile -> debug will often be repeated many many times before the compiler is happy with it. Luckily, the compiler never ever gets cross during this process - the programmer on the other hand...
It should also be said at this point that it isn't actually necessary to write the entire program before you start to compile and debug it. In most cases it is better to write a small section of the code first, get that to work, and then move on to the next stage. This reduces the amount of code that needs to be debugged each time and generally creates a good feeling of "getting there" as each section is completed.
Finally though, the compiler will present you with a program that the computer can run: hopefully, your solution!
The final step in the grand programming process is that of testing your creation to check that it does what you wanted it to do. This step is unfortunately necessary because although the compiler has checked that your program is correctly written, it can't check whether what you've written actually solves your original problem.
This is because it is quite possible to write a sentence in any language that is perfectly formed with regards to the language that it's written in (syntacticly correct) but at the same time be utter nonsense (semantically incorrect). For example, 'Fish trousers go sideways.' is a great sentence - it's got a capital letter and a full stop - but it doesn't mean a lot. Similarly, 'Put the ice cube tray in the oven.' has verbs and nouns and so on - but it's pretty useless if you wanted to make ice cubes.
So your program needs to be tested, and this is often initially done informally (or perhaps, haphazardly) by running it and playing with it for a bit to see if it seems to be working correctly. After this has been done, it should also be checked more thoroughly by subjecting it to carefully worked out set of tests that put it through its paces, and check that it meets the requirements and specification - but we shall discuss this more later on in the course.
Where mistakes are identified, it is a case of donning a Sherlock Holmes hat and trying to figure out where in the code the mistake is. Once identified, the problem should be fixed by changing the code and recompiling. Care should be taken at this point that this fix doesn't break something else, so careful retesting is important. This process is also known as debugging.
Once all the testing and debugging has been completed, you should be pretty certain that your program works according to your requirements and your specification and so you should finally have a solution to your problem!
Easy isn't it?!
While this may sound like a great deal of effort to go to to build a simple program, don't worry, as after a while it will become second nature, and for small programs, most of the stages can be done in your head.
The next section will introduce you to your first programming language, and your very first program!