Things to do before starting to code

There were a lot of things that were suggested for a developer to do before jumping straight at the computer to start coding. It is strange that though I have been one of the same, wanting to jump and write some code at a particular point in my career (quite early on) now it is quite the opposite. In fact now that I have been involved with teaching and training, I have seen a lot of developers skip the basics, so I thought this article could help you cover those basics and kind of catch up.

Rather than use a lot of superfluous words, let me cut straight to it, to have structured program, you need to have an outline of what you are intending to do, this gives a framework and helps solve issues which make programming easier, so let's start with sketching an outline.

STEP 1
Here's a sample from one really old book on Basic programming, where the example is provided on writing the steps for a simple Noughts and Crosses program. The program is build in phases and though this may produce more lines of code than normal, this will help debug and improve each of the modules easily.

Setup Initial Board
  Computer Move
   (A) Check if Middle Square Empty,
     If not move there
   (B) Check if there is a computer winning move,
     if so make it
   (C) check if human will win on next move,
     If so block
   (D) if no moves are made, check to see if a random move can be made,
     if so make it
     if not declare a draw
   Print Board
  Accept Player Move
   Print Board
  Check if player has won,
   if so Stop
  Goto Computer Move

You can see that the outline has provided quite a clear idea of how and what the game will do and all expected alternative actions to be taken (if any)

STEP 2
The second step in this process is to turn the sketched outline into a series of calls as follows

10 REM NOUGHTS AND CROSSES
 20 GOSUB 9000: REM Initialise
 30 GOSUB 1000: REM Computer Move
 40 GOSUB 8000: REM Print Board
 50 GOSUB 2000: REM Accept player Move
 60 GOSUB 8000 REM Print Board
 70 if human has not won AND computer has not won THEN GOTO 30
 80 PRINT "Congratulations"

This is the ancient Basic code, this can be translated to modern day languages as functions, so each of the GOSUB routines can be translated to functions and so in Lua the same code would read as

--Noughts and Crosses

 initialise()
 repeat
   computerMove()
   printBoard()
   playerMove()
   printBoard()
 until (hasHumanWon == false and hasComputerWon == false)
 congratulate()

Again there are some differences between the languages and the way the programs worked in those days vs the technologies and the way the apps work today. There was no event based programming and everything was run from a central dispatch loop, which kind of controlled everything. In the modern applications, touches/player inputs are independent of the loop and can fire anytime.

The subroutines can be then further enhanced to work modular as

2000 REM Computer Move
 2010 LET move = 0: REM if this is 1 then a valid move is found
 2020 GOSUB 2200: REM check if middle square is empty
 2030 IF move = 1 THEN RETURN
 2040 GOSUB 2400: REM check if a possible move exists
 2050 IF move=1 THEN RETURN
 2060 GOSUB 2600: REM check if a possible Human win can be blocked
 2070 IF move=1 THEN RETURN
 2080 GOSUB 2800: REM check if any move at all can be made
 2090 IF move=1 THEN RETURN
 2100 REM a return with move=0 means no further moves are possible
 2110 RETURN

So you see that it makes good sense to flesh out the structure and adding/changing anything is much easier than wading through spaghetti code.

I cite this example as I feel that the authors at the time did a very good job in explaining things, Universities and Schools are now run with teachers, that are not exactly qualified or educated in this discipline and the man's best friend, no not a dog, Google is not very helpful in teaching basics as today is the age of I want it all and I want it now.

I did not even touch upon the flowchart, which was what the era prior to this structured outline asked for. So if you can put together a visual plan on paper before coding starts, it is easier to work/manage it better.

Hope there was something that you could get out of it.

cheers,

?:)