Atma Xplorer

Xploring Games, Computing, Photography

Guide to Programming Series: Week 3

I’m a bit distracted as I was editing this (I’ve had the post ready for about a week which awaited minor changes) because I just got to view my grades today. Although it’s mostly 7.00 (Incomplete) I’m glad I don’t have to pay for tuition next school term. ^^ Finally I allocate my funds onto more uhm, personal stuff. A new computer, a new laptop… but before that I guess I’ll start answering positively to the job offers that have been coming my way.

Also, I noted that Week 2‘s series was too long. It probably bored everyone so I’ll snip things off to size so that it’ll be manageable for everyone.

Now, on with the 3rd entry of my Guide to Programming Series, Writing a program.

Whenever, on impulse, you decide to sit down and start writing a program, you’re likely to mess things up. In terms of cooking, it’s like doing it without a proper set of instructions and praying that the dish will turn out right.

For simple programs like those taking user input and displaying it on-screen, you can mostly get away without much planning but to be able to create something complex, you want to take time to design your program before you type a single code. If you know how your program will flow, how it looks and what it can and can’t do, then writing code will be a straightforward task.

A keyboard

Before You Write Your Program

An unplanned project is likely to end up with a program that doesn’t work, behaves strangely or solves the wrong problem. The decision to stop development at this point is highly likely, because although you’ve invested a lot of time and effort what you’ve ended up with is simply unworkable or isn’t worth salvaging.

Planning ahead helps you avoid this development deadlock and gives you some margin for experimentation. Keep these in mind when designing a program:

  • Who’s going to use your program?
  • What computer (OS) will run your program?
  • Will you work on it alone or with a team? If you’re on a team, what parts are yours and what aren’t?

At the design stage, it’s best that you don’t base your development framework on what programming language you will be using. This is to prevent you from being sloppy and assign things that you can design yourself to be handled by the language (exceptions, typecasts). Once you know exactly what you want your program to do, decide on which programming language might be easiest to use or will suit your system and/or needs.

Pages: 1 2 3


Comments ( 2 )

Have Something To Say ?