Although I have written quite a few programs as part of my Computing course, I don't consider myself a paticularly knowledgeable programmer, I'm really just a beginner. But from watching how others on my course wrote their programs, I can give you a few tips that will help you a lot, whatever language you use. These tips are designed for beginners, not secret hot-code for experts to use. They sound very obvious tips, but I watched lots of people beating their head on the desk because they hadn't done these "obvious" things and now had major problems.
IFs, FORs, WHILEs
Initially i had problems keeping track of all these things. But within a very short time I found that the easy way was to write down the start, middle and end of these bits of code, then fill in the details. For example, I'd start an IF like this: -
| if (x>10){ | /* start if x>10 | |
| } | ||
| else{ | ||
| } | /* end if x>10 |
By marking the start and end immediately, there is much less chance of forgetting to end it, by putting in the comments, I know which particular if I'm looking at. If I entered, say, a for loop in the middle of this, I'd mark its start and end, to avoid confusing it with the if end point. These may seem very trivial points, but having watched my friends struggling to do this, it soon became clear this was a very good way to work.
Meaningful Names
So what do you think the if above is checking? The value of x, but what is x? Suppose it said if{(age>10) would things be a lot clearer? Of course it would. You will get marked down on a computing course if you don't use sensible names for your variables, so start with meaningful names from the very beginning. When you come to upgrade the program in a few months time, do you think you would remember all the cryptic x, y, mx, ccu, ty-p3 variables' meanings? But if it was age, date, address, and so on, life would be very much simlper.
Plan your Program - Pseudocode
Because I was ordered by my boss to go on a computing course, I had almost no prior experience of writing programs, apart from a tiny one I wrote 20 years earlier, one about four years after that, and a brief three month play with an old copy of VB 4 and a textbook about three years before the course started. So as a complete novice, I felt I didn't know where to start when we had our first lessons, and to try to get things moving, I usually wrote down the various steps I thought the program should go through, using short phrases to summarise things. I did notice that I always started the actual coding after everyone else, but strangely I almost always finished sooner, and with a better program, than the others in my class, who just dived straight in.
Then we got the lessons on Pseudocode, Structured English and Stepwise Refinement.
I had been using this technique unknowingly from the very beginning. Notice I said technique, and not techniques. In reality, they are all the same thing. Stepwise Refinement means you write down the big steps that the program will carry out in the correct order and check that the order IS correct, then expand on each of these steps, and expand on each part of the expansion, until you are so close to writing code, you might as well do it. This way you discover the bits you need, the order things must be done in, you watch out for loops starting and ending on the correct values, you notice where you need the menu, repeat or exit options and so on. The language of Stepwise Refinement is Structured English which is plain old english with a few programming words thrown in, such as IF, END IF, FOR, END FOR, WHILE, ENDWHILE, DISPLAY and the like. Pseudocode is another word for Structured English. Several students in my class thought these were all different things and got confused at times.
In the examples that follow, the words in UPPER CASE are key computing terms with exact meanings, the rest are just plain english descriptions, the combination is pseudocode, written in structured english. When developers find themselfs using the same general technique, they tend to give it a clever sounding name, and that's all that's happened here.
So you might have a program which is summarized in your mind as: -
| Input password |
| Check password |
| IF password okay |
|
| ELSE Exit program |
| ENDIF |
This could be expanded by stepwise refinement to read
| DISPLAY message"Enter name" | |
| GET input = nameIn | |
| DISPLAY message "Enter password" | |
| GET input = passwIn | |
| GET file allpassw | |
| Search for nameIn in allpassw | |
| IF nameIn found | /*First IF starts |
|
|
|
|
|
|
|
|
|
|
|
|
| ELSE DISPLAY message "Incorrect combination. Goodbye." | |
| ENDIF | /*End First IF |
Nowhere does it say how to read the file containing the passwords, how to find the password matching the user name, or what happens when access is allowed, these bits would be refined (expanded upon) next. You could write a short stub for the "allow access" bit, which simply displayed a message saying "You're in" and an exit option, while you concentrated on getting the password checking to work, and testing it for problems. Then when the password checking worked, you can then move on to what happens after they are allowed access to the system.
You might expand "allow access" to display a menu offering five types of maths quiz to be played, with a quit option and a take the test again option. You would expand on the menu and how to exit the program in the same pseudocode style and for convenience it is usually done on a seperate page. Then each quiz would be planned the same way, and written seperately. If you are using functions, each main part could be a function by itself, with perhaps other functions inside it. Refinements which you know are likely to form a major part of the program can be done seperately to the main structure on another page, to avoid loosing sight of the overall structure.
Planning like this before you start makes life so much easier for you. Yet time after time I heard my classmates complaining that they were stuck, and it usually turned out that they had no plan, no pseudocode to work from, no idea what should happen next in their program. No design in other words. Pseudocode is very much easier and quicker to write than real code, so if you can't get the pseudocode written and make sense of that, there is NO WAY you will get the program written in a sensible time. I even saw some guys writing the pseudocode AFTER the program, because they were required to show pseudocode as part of the assignments. This is so stupid - it's like building a house, moving in, then drawing up the blueprint plans and the electric wiring diagram, to show that the house was well planned!
For another example, see the More Pseudocode page.
Indentation and Comments
Notice the use of indentation above. It is very important to do this, as it helps you find the start and end of each sub-section of code. If you think it doesn't matter, imagine reading through a few hundred lines of code with no indentation - you'd spend all your time trying to track down the start and end of each section. Do it, you know it makes sense.
You should also add comments to your code as you go along. I've used /* to mark the comments above, you should use whatever the comment style is in the language you are using. Because when things go wrong, as they definitely will, you will then know what the code is supposed to be doing. It soon became clear in my class that those who wrote pseudocode, indented IFs, LOOPs, WHILEs etc, and commented the code were finding things very much easier. Some guys thought that they were just being told to use some technique for the sake of showing that you could do it, but it really makes programming so much easier if you start it this way.
Functions or Modules
Some languages use the term function, others use the term modules. They are self-contained pieces of code that do a single thing, and hopefully they do it well. These are sections of code that you will re-use several times. Sometimes they are very short, sometimes they are about half a page long. If you are using a menu, then write it as a function. If you have a title you wish to display several times, write it as a function, if you have to calculate the score after playing a level of a game, write it as a function. Then every time you need to use that piece of code, you only have one line to write, to call the function.
Sometimes you can split up a larger function into a set of very short functions and use different combinations of them as appropriate, making several similar but slightly different functions to suit different needs.
A program can end up as a list of main functions to be run, and several of the main functions may use smaller ones inside themselves. And then you start to notice that the program looks very similar to the pseudocode before it was expanded! That usually means you've got it right.
These are all general guide lines for beginners to programming. But they are almost always things that you are required to do to get a high grade for your work. They also make following your own work much easier. In short, they are the correct way and an efficient way to program.
Text Books
Read text books. The Internet is NOT the be all and end all of advice on computing, although it is good. Remember anyone can write a web page, they may not be an expert on the topic and may even make mistakes - I've seen plenty when looking for help myself. Some pages may even be just another student's coursework, put up for his/her mates to look at. And if you automatically trust an unknown student to be the one your grades depend on, you could be sadly disappointed when you get the work back!
For C programming, I used Deitel and Deitel's C: How to Program. The other students on my course also found this to be very good as well. As C is a very complex language, any book of less than 300 - 400 pages must be missing a lot - go for the bigger, 1000 page books if you want to learn a lot. The same is true for Visual Basic, and any other complex programming language. Deitel and Deitel have a book on each of the popular programming languages which are all big sellers, and can be recommended as ideal texts. But they are not cheap. You get what you pay for however.