SQL and VB

[KenHigg]

Like I said, it goes beyond the example we are working with. If you get in the habit of breaking down the code into logical pieces when doing simple routines, when you have to write more complex routines the methodology comes more natural.

For example, if you had three conditions you need to meet before you execute the primary part of the routine, using your method you could have something like:

if condition 1 is true then
   if condition 2 is true then
      if condition 3 is true then
         Do the prmary part of your logic
      else
         Warn the user condition 3 was not met
      end if
   else
      Warn the user condition 2 was not met
   end if
else
   Warn the user condition 1 was not met
end if

This is like spaghetti code to me and gets real hard to follow real fast. This is much easier for me to follow:

'Testing section---------------
if condition 1 is false then
   Warn the user condition 1 was not met
   exit sub
end if

if condition 2 is false then
   Warn the user condition 2 was not met
   exit sub
end if

if condition 3 is false then
   Warn the user condition 3 was not met
   exit sub
end if

'Logic section---------------
Do the prmary part of your logic

 

[Rabbie]

Ken, I was using a simple routine to do one task SO WHAT WAS YOUR PROBLEM. I was dealing with a simple problem and giving a simple viable solution. Your example shows you have nt worked wih assembler or machine code when you would see REAL spaghetti coding jumping hither and thither. If you don't use goto's you don't get real spaghetti coding.

I must say that I find both the examples you give to be perfectly satisfactory and understandable. I wouldn't mark down one at the expense of the other. I agree with you about the desirability of working in logical units each kept in its own procedure so we are not really so far apart on this.

 

[KenHigg]

Sorry Rab, Sometimes I don't explain things very well and I wasn't sure I was getting my point across.