Parkland College 2400 West Bradley Avenue, Champaign, Illinois 61821

Csc 123, Csc 125 Online, Csc 125 Traditional, Csc220

The Best Way To Program, Guaranteed*

Fall 2006

I've seen many students get frustrated because they write the whole program first, then they compile it for the first time, and then try to get rid of all the errors.  When they finally get the program to compile without errors, they think they are almost done, but they are only getting to the hard part.  They discover that their program does not work the way they want -- logical bugs -- and they have to re-write most of the code because they had an incorrect design.  This is a VERY frustrating way to program. 

The solution is to start with the minimum possible program, just

int main()
{

    return 0:
} 

Then add just a few lines of code, no more than two or three, that you think will make the program run a little more like the program you want.  Also add some debugging code to make sure the code you added is doing what you think it should.  (Usually debug code outputs some variable's value to make sure it is what you expected.)  Then compile, run, and test your program.  If there is a problem, it will probably be in those new lines of code, and will be much easier to find.  When you get the new lines of code working, comment out the debugging code but leave it in your program as a comment in case you need it later.  Then repeat the entire process with another two or three lines of code.  Repeat the whole process --- add lines, add debug code, compile, run, test, comment out the debug code --- over and over, each time getting a little closer to the completed program you want.  RESIST the temptation to speed ahead and add five, ten or more lines of code.  You will only end up going slower, not faster. 

Always add the easiest code first.  Get it working and out of the way, so you know you can depend on it. That is the way to succeed in programming, and also to get done more quickly.  When the easy parts of your program are working, usually including the input and output, you will have a much better platform to test the harder code as you add it, a few lines at a time.

I guarantee you, that you will finish faster this way than the frustrating "write the whole program first" method.  The secret is to ALWAYS have a running program, even though it is incomplete.  With a running program and only a few new lines of code, finding bugs is much easier.  Add features to your program, a few lines at a time, until it does everything you want it to do.

The statement "add a few lines of code at a time" begs the question, "How do I know what lines of code to add?".  The answer is a good design for your program, before you start writing code.  This is where diagrams and pseudo-code are useful, usually using pencil and paper,  Do not worry about the details, such as variable names.  The whole point of pseudo-code is to leave out the details and concentrate on the overall structure of the program.  Plan the whole algorithm in diagrams and pseudo-code, and make sure you are reasonably confident your algorithm is correct, before even sitting down with the computer.  When you start coding, get the easiest stuff out of the way first.  Then the correct strategy of adding a few lines of code at a time usually becomes obvious.     

One last piece of advice -- if you add a few lines of code and it doesn't work the way you want, be sure to REMOVE those lines of code, and go back to your previous working code.  If you leave the defective code in your program, you are just adding bugs!

This is the best way to program.  Guaranteed!*
 

* If you have found a better way of programming, notify the instructor at  sbadman@parkland.edu and explain your programming strategy.  If, in his august judgment, your strategy has a chance of being better, he will write your program using your strategy.  If your strategy actually is better, he will give you the program and will give you an A for the assignment (since the program will be perfect, of course).  This does not constitute plagiarism, because you can freely use in your assignments any code you get from the instructor .  The instructor is the sole arbitrator of "what is better" and "what has a chance of being better".  By reading this page, the student agrees not to bring academic charges of silliness against the instructor, nor to whine if the instructor judges the strategy "not better".  This is the sole statement of "The Best Way to Program" guarantee.  No other guarantee, express or implied, is applicable.  Offer void in Alaska, Mississippi, and the Pacific islands nation of Vanuatu.