Qbasicnews.com

In a recent discussion, someone asked if FlowCharts were out of style. This prompted an off-forum discussion between myself and a few others in here about how we approach a new project. Some of us just sit down at our keyboards and start writing..... while others plan their work in advance, in varying degrees. Obviously, there are many different ways to go about writing a program in QBasic, (or any other language).

As for me, I use a highly structured and planned method for writing my programs. Most of my work is actually completed on paper (or on a LOTUS spreadsheet) before I ever begin coding. I start out with formally defining the problem... then move on to required inputs, processing steps, and desired output. Next I do a rough flow-chart, then a detailed flow-chart.... and finally a Code / Screen Display Sheet. The work actually done within QB71 is largely limited to bulk typing the program from the code sheet into the computer, and compiling it. It's the old method taught by IBM back when computer time was wildly expensive, programmers were relatively cheap, and error codes were insanely cryptic.

I'd guess that something similar is still taught to student programmers in colleges.... and they all roll their eyes with disdain at how clunky it is.

I use this method for the following reasons:
1. It enables one to trace logical flow easily, and detect those unforseen multiple loops that we all love so much.

2. It allows me to draw and visualize the screen outputs very quickly. This works well for text out puts .... but I don't do graphics, so it may not work for everyone.

3. It frees me from having to sit at my keyboard for a long time. I can take my notebook anywhere, and work in any comfortable position that I choose. (I guess I could use a laptop for the same thing..... but I don't have one.)

4. I'm set in my ways, and been doing it this way since Nixon was president....and yes, I have short hair, and wear white shirts...... but I don't wear plastic rim glasses. I have small wire frames, like John Lennon. ( Actually, this is probably the REAL reason I do things the way I do! )

So..... That's the "IBM /Dave / Nixon Era" approach. What I'd like to know is how YOU guys approach a new program. Do you keep it all in your brains, and just code it directly? Do you plan your work out? How do you do it?

Dave

With C++ and QB, I just dive in. But by the time I do, the idea has already been running around in my head for a while. Any planning I do is mental, except for the occuational one-liner note-to-self here and there in the program.

In asm, I might do a little C/QBish pseudo-code first. I know it's counter productive to think like a compiler, but sometimes it helps when it gets to complicated to visualize in it's entirety. Or sometimes I try something simpler first, then work it into what I need.

A lot of design decisions in my projects are made by trial and error. I suppose I could benefit from doing a little more preperation/planning.

I agree,

QB/C/C++ just dive in if the proj is simple. If too complicated I write down the idea and then expand on by writing Functions/Sub names and their use and then dive in =P

I usually just dive in! Heh heh... This does work sometimes, though I do find myself getting completely lost sometimes, and think that maybe a structured plan might have helped somewhere along the way.... :bounce:

I kind of like the XP (Extreme Programming) approach, where the basic idea is start with a very small subset of what the final program will do and make that work completely. For a large project you can actually have something up and running in a few short weeks. If the code is kept flexible then it also allows you to change your mind quite frequently on what features you want in the program.

I dont really map things out too much on paper (Im more like Sterling, I have an idea in my head for a while before coding) but I do draw diagrams and things to work out more complex parts of the code.

I recently finished working on an application in Java for creating Guitar Tablature, which I worked on with four other people for my 3rd year software engineering project using the XP approach. Most of the planning for that was done by calling meetings and then arguing over different design points on paper or a whiteboard. The final project contained over 12,000 lines of code, not including testing code, code that was scrapped and replaced (happens reasonably often) or documentation.

I think the approach taken really depends on what you are doing, most small projects are easy to just dive straight into, but larger projects, especially where you are working in teams do require some amount of forward planning and frequent planning meetings during the project to deal with unforeseen problems.

i dont need any planning at all because all i do is short one day projects that i never complete. i know thats not good but who cares i am only 12 so stop making fun of me.

For games I write down the storyline, sketch graphics and the interface ahead of time, and make notes of ideas as they come.

For other programs, I find myself making it simple, then a few weeks later coming in and making a project out of it. This really teaches you to document code well....

But most of the time I jump right in.

I'll dive straight in if it's an easy part of a program, but at a tricky part where the algos may get a little heavy, I normally write the code out on a piece of paper, and choose some certain values for variables, plug them in manually and work out the result. This way I can rewrite the code but still see the changes I made and why.

And I know I should use an errortest routine

I wish I was clever enuf to sit down at the keyboard and straight away begin pounding. More than enuf of my customers want to see what their output is gonna look like before committing. Like D1D I usually have to prep lotsa examples then write up how to achieve the selected one(s), hence I have numerous project papers, flow-charts, written source codings etc. filed away. The 'puter revolution sure did NOT do away with the paperwork, for me anyway, but I still enjoy the daily grind with a grin.

Cheers fellow travellers. :bounce:

Personally, I tend to cut through a project by working on it in sections, of which I know I'll need certain ones, and I'll need to create some before I can make the rest.

Usually I start with enough data structures to get the renderer working, then I finish the renderer, then usually I finishe the rest of the data structures and start the controls followed by scripts, then I add multimedia support, then I draw up any completely seperate routines, such as menus, and by then I usually have an engine on my hands.

The only problem is that I tend to refer to everything as a seperate "engine", which really pisses off traditional programmers. ^ ^