locked
How to design a program RRS feed

  • Question

  • I was looking through the code for LitDev's program (BNW650) he wrote for the Rocky's Boots thread.  I printed the thing out and it is 9 pages of size 8 font.  I admit I am an awful programmer.  I learned on Apple BASIC and Pascal in '83 while trying to teach a high school programming course.  Everything else I have learned has been from teaching and one really bad college Java course.  I beat the program I want to write into submission by sitting in front of a keyboard and typing trial and error code.  As a high school teacher this method works because all I usually do is write little programs for teaching purposes.  I also write some simple stuff to solve Project Euler problems.  This method works just fine for little stuff but I just cannot picture it working for 9 pages of size 8 font.  Is there some tool, book/s or whatever for teaching amateur programmers (high school programming teachers are usually not pros by any definition, at least not the ones I have met) who want to write something more than 100 lines how to design a program before sitting down to write code?  I have been looking for a few years but no luck.  I know what a flow chart is but that does not seem to suit larger programs.  I am working with some pretty sharp kids using VB but all we really do is hack on code.  No designing or real planning.  If I go to any book on programming it is “type this to get this to happen”.  Nothing on good design methods.  Is there something out there that will help me program and teach programming better?

    Monday, January 18, 2010 11:53 PM

Answers

  • I haven't come across any good general guidelines, but here's my thoughts.

    1] Think about the whole project and work out in a bit of detail what you want it to do in total (not necessarily how it will do it, but rather what you want it to do) - then write a stub routine for the 'main loop' such as:

    Initialise()
    While ("True")
      process_event_flags()
      do_some_calculations()
      update_graphics()
    EndWhile


    2] At the same time think about some of the lowest level details (concentrate on the fine details of exactly how some required calculation or operation can be achieved) and prototype these such as:

    set_event_flags() - mouse and keyboard - anything the user does
    detect_a_collision()
    initialise_the_window()
    rotate_an_image()
    calculate_angle_between_objects()

    3] Decide on the main data (arrays etc) and give them good names and set them up in the Initialise() subroutine.

    4] Work from the detailed prototype subroutines that do one task and have clear input and output functionality - gradually add these to the main code.  Try to keep each subroutine relatively short - at least conceptually if not in lines - so it only does one thing and calls other subroutines to do lower level isolated tasks.

    5] Try to end up with a structure that uses subroutines so that the main loop only calls subroutines that perform specific tasks, and each of these is broken down into subroutines that perform specific tasks.  It should end up a bit like a tree, with more and more detail being developed in the low level subroutines.

    I find it easiest to work by getting a good overall idea of the structure and functionality (including main data required), then working from both the whole program (top level) and small prototype tasks (low level) bringing them together bit by bit, gradually meeting in the final project.

    Finally, comment the code usefully - why you have done something, describe underlying physics model or assumptions - anything you noted while testing that isn't obvious etc.  Even better, describe the functionality, input and output data that each subroutine is expected to use or change.  We are all a bit lazy here.

    On the point of testing, especially consider things that could go wrong with the low level detail subroutines and make these as solid as possible - consider division by zero, unexpected subroutine input data, user error etc.
    • Marked as answer by Vijaye Raji Thursday, January 21, 2010 8:49 AM
    Tuesday, January 19, 2010 9:42 PM
  • Programming is like painting. You start with an idea and a blank canvas, add a basic wash of colour, then increase the depth and complexity until you have something like your initial idea. 

    A computer, and therefore a computer program, (to date) consists of four elements: Input / Storage / Processing / Output...

    Input = getting the paint
    Storage = putting the required amounts onto the palette
    Processing = mixing the paint into the required shade
    Output = transferring the paint to the canvas

    So, to get started in any program, small or ultimately complex, start with the basic 'wash' - which is the Main Loop (as LitDev shows in his example point #1).

    On top of the Main Loop, you slowly and very Methodically add smaller Subroutines or Functions to create something that will become part of the whole. Normally, these consist of waiting for an event to happen (i.e. an Input of some sort, or the result of some other Processing), then responding to that event (either requiring more Input, some Storage or an Output).

    The key to this is being Consistent; remember, you will need to understand it all when it gets more complex, so keep each element as simple to understand as possible and add comments regularly and often. Make all your variables easy to understand and relevant to what their purpose is; name your Subs/Functions based on what they do, or what part of the overall program they belong to. But, whatever approach works well for you, above all, use it consistently so you understand easily what you were thinking when you initially wrote the code.

    Your first attempts will be big and bloated as you will write many Subroutines or Functions that do fairly similar tasks but in slightly different ways. As you get more comfortable with structuring your code in this way, you will begin to see ways to make each Sub/Function useful in multiple places with some slight tweaks - this is where you gain over a painter, who has to paint every leaf/bird/blade of grass, but you can as a coder make one Function to create a bird, then call it repeatedly to make many of them.

    Once you have mastered the approach of building small supporting Subroutines/Functions then there is no real difference between a small or a large complex program.  The hardest part is teaching yourself the discipline to stick to your consistent methods, not to get sloppy and just bash something together.

    Good luck, it's great fun (mostly!). Personally though, flowcharts work well for me whether for a large, 9 page program, or a small 1 page one.
    • Marked as answer by Vijaye Raji Thursday, January 21, 2010 8:49 AM
    Tuesday, January 19, 2010 11:04 PM

All replies

  • I haven't come across any good general guidelines, but here's my thoughts.

    1] Think about the whole project and work out in a bit of detail what you want it to do in total (not necessarily how it will do it, but rather what you want it to do) - then write a stub routine for the 'main loop' such as:

    Initialise()
    While ("True")
      process_event_flags()
      do_some_calculations()
      update_graphics()
    EndWhile


    2] At the same time think about some of the lowest level details (concentrate on the fine details of exactly how some required calculation or operation can be achieved) and prototype these such as:

    set_event_flags() - mouse and keyboard - anything the user does
    detect_a_collision()
    initialise_the_window()
    rotate_an_image()
    calculate_angle_between_objects()

    3] Decide on the main data (arrays etc) and give them good names and set them up in the Initialise() subroutine.

    4] Work from the detailed prototype subroutines that do one task and have clear input and output functionality - gradually add these to the main code.  Try to keep each subroutine relatively short - at least conceptually if not in lines - so it only does one thing and calls other subroutines to do lower level isolated tasks.

    5] Try to end up with a structure that uses subroutines so that the main loop only calls subroutines that perform specific tasks, and each of these is broken down into subroutines that perform specific tasks.  It should end up a bit like a tree, with more and more detail being developed in the low level subroutines.

    I find it easiest to work by getting a good overall idea of the structure and functionality (including main data required), then working from both the whole program (top level) and small prototype tasks (low level) bringing them together bit by bit, gradually meeting in the final project.

    Finally, comment the code usefully - why you have done something, describe underlying physics model or assumptions - anything you noted while testing that isn't obvious etc.  Even better, describe the functionality, input and output data that each subroutine is expected to use or change.  We are all a bit lazy here.

    On the point of testing, especially consider things that could go wrong with the low level detail subroutines and make these as solid as possible - consider division by zero, unexpected subroutine input data, user error etc.
    • Marked as answer by Vijaye Raji Thursday, January 21, 2010 8:49 AM
    Tuesday, January 19, 2010 9:42 PM
  • Some references on the formal "Structured Design": http://en.wikipedia.org/wiki/Structured_analysis
    Explore the wiki a bit, it'll show you some of the diagrams used for structured programming design, which includes the all important Flow Chart.

    http://www.yourdon.com/strucanalysis/wiki/index.php?title=Introduction
    This wiki contains an entire book by one of the inventors of structured programming, Ed Yourdon.

    Remember that this method is very formal and a bit old-fashioned. Try and pick up what you can about structured design, and just continue hacking in the mean time. litdev's method above will work for any project you'll want to pick up in the near future. The key is to start from the top, and split your overal design in increasingly smaller subroutines.

    Hope it helps. If anything is unclear, just ask :) .
    Tuesday, January 19, 2010 10:42 PM
  • Programming is like painting. You start with an idea and a blank canvas, add a basic wash of colour, then increase the depth and complexity until you have something like your initial idea. 

    A computer, and therefore a computer program, (to date) consists of four elements: Input / Storage / Processing / Output...

    Input = getting the paint
    Storage = putting the required amounts onto the palette
    Processing = mixing the paint into the required shade
    Output = transferring the paint to the canvas

    So, to get started in any program, small or ultimately complex, start with the basic 'wash' - which is the Main Loop (as LitDev shows in his example point #1).

    On top of the Main Loop, you slowly and very Methodically add smaller Subroutines or Functions to create something that will become part of the whole. Normally, these consist of waiting for an event to happen (i.e. an Input of some sort, or the result of some other Processing), then responding to that event (either requiring more Input, some Storage or an Output).

    The key to this is being Consistent; remember, you will need to understand it all when it gets more complex, so keep each element as simple to understand as possible and add comments regularly and often. Make all your variables easy to understand and relevant to what their purpose is; name your Subs/Functions based on what they do, or what part of the overall program they belong to. But, whatever approach works well for you, above all, use it consistently so you understand easily what you were thinking when you initially wrote the code.

    Your first attempts will be big and bloated as you will write many Subroutines or Functions that do fairly similar tasks but in slightly different ways. As you get more comfortable with structuring your code in this way, you will begin to see ways to make each Sub/Function useful in multiple places with some slight tweaks - this is where you gain over a painter, who has to paint every leaf/bird/blade of grass, but you can as a coder make one Function to create a bird, then call it repeatedly to make many of them.

    Once you have mastered the approach of building small supporting Subroutines/Functions then there is no real difference between a small or a large complex program.  The hardest part is teaching yourself the discipline to stick to your consistent methods, not to get sloppy and just bash something together.

    Good luck, it's great fun (mostly!). Personally though, flowcharts work well for me whether for a large, 9 page program, or a small 1 page one.
    • Marked as answer by Vijaye Raji Thursday, January 21, 2010 8:49 AM
    Tuesday, January 19, 2010 11:04 PM
  • I have one more comment to add to this discussion, and it reiterates a point DW made. And, I am going to state it as both a positive and a negative.

    • Do not become overly fond of your code.
    • A simple code review can be your best friend.
    Defining what programming is can be a trick. It's not really math. It's not really engineering. It's not really a language. It's not really an art form. But at the same time, it has parts of all of those things. The odds of getting it right the first time are pretty slim. Having a plan from the start is important if you ever want to reach a goal; but having a critical eye is even more important, in my humble opinion.

    As you code, stop yourself every so often. Take a look at what you have written. If it seems silly, inefficient, or difficult to follow, go back and rewrite it. You will find that your programs become more reliable. In the long run you will find that you have developed a knack for the design process.

    Saturday, January 23, 2010 11:33 PM
    Answerer
  • I am not a professional programmer by any means, I just do it for fun.  I've taken a few classes over the years.

    Flowchart the problem.

    Modularize the problem using the flowchart.  Each module should clearly define what the input will be and what the output will be from/to the main program.  This will be different in Small Basic because of the global variables, but the principle can still be used.  The module description should be such that someone could program the module without having knowledge of what the rest of the program does.

    Use the module description to write pseudo-code, or a plain English description of what each step of the program should do.  Then translate the pseudocode to real code.

    When I am actually typing the code in, I am just translating what I already have written down.  I don't try and figure out logic while typing code into the computer.  The logic has to come first for me.
    Sunday, January 24, 2010 8:23 AM
  • I worked as professional programming for 12 years, and I never wrote a single flow chart during that entire time. The larger the idea, the more important it is to have a detailed plan from the start; but formulating that idea into something like a flow chart is over rated.

    Here is a quote from the professor who taught my Software Engineering class when I was earning my masters: "The design methodologies we will learn in this class are intended for large projects. If your program will only have a few hundred, or even a few thousand lines of code, then forget about the design process. Just sit down and start hacking."

    At the level of stuff you can do in SmallBasic, spending a lot of time on design is not needed. Just get in there and start hacking.
    Thursday, February 4, 2010 8:48 PM
    Answerer
  • Here is a quote from the professor who taught my Software Engineering class when I was earning my masters: "The design methodologies we will learn in this class are intended for large projects. If your program will only have a few hundred, or even a few thousand lines of code, then forget about the design process. Just sit down and start hacking."
    I am so, so glad your professor didn't decide to become a driving instructor!
    Friday, February 5, 2010 11:39 PM
  • If you have a lot of experience "it down and start hacking" is a very successful method.  But looking at it closer that is not realy what you are doing, you have a good mental plan based on years of experience.  A novice does not have those years and therefore needs some type of non-code based structure to build a program on, be it 10 lines of code or 500 lines.  I can see a quote like that coming from a college professor, most of them do not teach novices.  Beginning high school students cannot "sit down and hack" because they cannot hack in any position.  It is also not a real good methodology to teach to them.
    Monday, February 8, 2010 5:07 PM
  • I have to disagree with you Loyola. I would argue that the idea of being able to just sit down and pound out some code is the entire point of SmallBasic.

    I was twelve the first day I encountered a PC, and I started programming that same day. There are two reasons why this was successful. First and most obvious was that there wasn't much else that one could do with a PC in 1982 other then fiddle with the BASIC interpreter. The more important reason was that BASIC was easy. My father showed me how IF and For worked, and I figured out the rest by trial and error. Write some code, run to see what it does, change the code a little, repeat.

    If someone had told me that I had to sit down, work out the logic ahead of time, draw a flow chart; to know where I was going and how I was going to finish thing before I started... I would never have started in the first place.

    Programing can be a constructive form of play, like legos. But if you take the play out of it, by insisting that beginners follow a set of arbitrary rules you suck a lot of the fun out of programming. The starting projects I assign my Intro to Programming class are to just have some fun and get them used to using the system. The first is some Ascii Art. Using the Textwindow object and keyboard characters they have to draw an artistic version of their name. The second project is some vector art. Using the Turtle object the students draw a design of their own. By the time they are done, they are curious about what else can be done, and interested in learning new tools. Intro only covers some basic tools, variables, the If statement, and looping (goto, for and while). Most of the time is spent creating projects, so there is lots of positive feed back.

    If their interest holds and they stick around for a second semester, then we can start talking about problem solving and algorithms.

    Program design isn't for novices. Get in there and pound out some code. If you find that you are having fun, and have a knack for the process, then you can start researching algorithmic development and taking courses to fine tune your skill.
    Monday, February 8, 2010 9:04 PM
    Answerer
  • It depends on the programmer - there aren't right or wrong ways, but there is good and bad code. 

    Good code will have a logical structure with subroutines performing single logical tasks; whether that was worked out on paper, all in the programmers head from the start or arrived at after many trial and error 'hackings' doesn't matter.  All methods are useful.

    From the perspective of SmallBasic, I think playing, modifying other peoples code, exchanging ideas with others and generally hacking about is a great way to learn and is most fun, but there will come a point when the programmer will discover for themselves that good structure will get them further quicker and then any approach that works is good.
    Monday, February 8, 2010 9:21 PM
  • Coding Cat, I understand you approach to teaching beginners and cannot disagree to the method.  Programming should be fun to start with to attract fresh meat, opps, I mean new talent.  I just do not like to see beginners start with bad habits and have to break them later.  I would like to find a way of doing both at the same time.  I just see lots of kids that started programming by hacking in code unable to get beyond that to the next level.  Hacking is just too much fun and if they have to think about it they do not want to be bothered any more.  Hacking is fun, I do it all the time but then I have never been taught a better way to do it.  I just do not think it is the best way to start out learning to program.  There has got to be a happy medium in there some where.
    Monday, February 8, 2010 10:49 PM
  • I like litdev's path on top, that's how I work.  For a beginner student in smallbasic you could skip functions altogether and just start by writing comment lines on what you want to do.  It would look like litdev's example but in pure english.  Then hack/slap code under each comment that does what you think it should do, and go back and forth repairing stuff that didn't turn out the way you expected.  They'll get the hang of if/else's etc this way.

    When they've done that a couple months, and program assignments begin to get larger, then start talking about functions instead.  They'll appreciate them then especially if the function gets used multiple times in your code.

    Maybe the trick is to add language elements a little at a time, each time to allow them to appreciate how it made something easier that they had to do before.
    Wednesday, February 10, 2010 8:41 PM