View Single Post
Old 01-08-2004, 04:54 PM
loquin's Avatar
loquin loquin is offline
Google Hound

Retired Moderator
* Guru *
Join Date: Nov 2001
Location: Arizona, USA
Posts: 12,400

I once worked with an older gentlemen named Walt. Walt was a great guy, but I believe that in every meeting he ever attended in his life, and at least a half-dozen times a day, he would use the expression that you "Need to get your ducks in a row."

Those $%)!$ Ducks! The Publicity they got! I used to get so irritated with that phrase. But, the more I think about it, the more appropriate the phrase seems to the field of programming. Although you can apply the concept of getting everything ready to go before you begin the next task in many areas in our profession, I really think those ducks may have the best application during the design process.

One of the areas where most of us can do a better job is in planning and preparation before actually writing any code at all. It's all too easy to just jump in, feet first, and begin coding. But, there's a real danger, that, if you do, you can lose track of the direction that your application is headed, and you can end up missing critical areas. Then, the re-writes begin, and the "I've spent so much time coding this area that I don't want to re-write it, so I can just tweak this a bit to compensate..." can begin.

The answer of course, according to those darn ducks, is to work on the project as a whole, at a high (or abstract) level, before coding anything at all, to ensure all requirements are met. Many programmers, myself included, use what is known as a stepwise approach here. First, define, at a very high level, just what the application or system is to accomplish. Then, at the next step, break out, or refine this concept to a series of processes or procedures. Complete this step, then break the processes or steps down further.

Each of the descriptions we talked about above can be thought of as pseudo-code. The first iterations through the process include pseudo-code that is very abstract, but as you refine the levels, the pseudo-code steps closer and closer to real VB code. Eventually, you translate the pseudo code to actual code, and the application is complete!

Well, Isn't VB/Basic about as close to pseudo-code as you can get? It seems 'Basic'-like code is often given whenever an algorithm is described with pseudo-code in books and such. Not Really. It's true that the Basic language was developed with the intention of following an English-language syntax as much as possible, which makes it somewhat closer than others (Pascal also adheres to a similar syntax, although more rigidly defined structure) but you have to remember, pseudo code can have different levels of abstraction which can make it very close to true code, or fairly far removed from code. Generally, I usually use the stepwise approach using pseudo code, in the design cycle. In this approach, you begin at a very abstract, "high" level, and gradually focus in, or step closer to code.

Under this methodology,
Process the File

Open the File
Scan the file line at a time, looking for key characters
Process the fields after the key characters
Close the file.
which in turn is expanded to code:
' Open the File iFileNo = FreeFile Open sFileName for Input as #iFileNo ' Scan the file line at a time, Do While Not EOF(iFileNo) sLine = Line Input #iFileNo ' looking for key characters If Instr (sLine,sKeyVal) > 0 then ' Process the fields after the key characters sTemp = Mid$(sLine, Instr (sLine,sKeyVal) + 1) sFields = Split (sTemp, ",") ' Build the SQL Insert command, execute ' ... End If Loop ' Close the file. Close #iFileNo
The level at which you, as a programmer, makes the step from pseudo code to code varies, depending upon your skill and experience level. As you get more experienced, the steps become larger and larger.

Both the above blocks are psuedo code (at different levels of abstraction,) which can eventually become the comments for the program, as code is added to it to support the functionality needed for the pseudo code.

The main advantage of pseudo coding first (aside from the self-documenting feature, that is) is that by forcing yourself to work more abstractly initially, you can work out the program logic flow first, before throwing code at the problem & getting bogged down in detail. The process results in a program that is less expensive to write.

Less expensive to Write??? How can THAT be, when you spend more time working you way through those steps? It's less expensive to write when using a step-wise design approach (or other structured methods) because you've spent more time, up-front, in ensuring that the application/system design is appropriate to your needs. You will spend less time in re-writes of code, and less time troubleshooting programming logic errors. An error fixed in the design stage is MUCH less expensive to fix than one discovered later in the project. Period. Your app will cost less to write and troubleshoot, and certainly, over the long run, have a lower total cost of ownership. In addition, because the app is laid out more logically, it can often be MUCH easier to troubleshoot, and will often be more reliable. Again, this is because more thought is given to the app during the design process. Finally, a well structured design will be easier and less expensive to maintain.

There are many different methodoligies used in the software design field, each with their own supporters. Some folks swear by flowcharting. (I swear AT them, myself ) Each of us need to find an approach that allows us to line up those ducks, though. Otherwise, on your next project, you may find youself chasing a wild goose.
"I have my standards. They may be low, but I have them!" ~ Bette Middler
"It's a book about a Spanish guy called Manual. You should read it." ~ Dilbert
"To understand recursion, you must first understand recursion." ~ unknown

Last edited by loquin; 10-21-2004 at 05:32 PM.
Reply With Quote