Troubleshooting problems

[sgbotsford]

I would have added this to one of the stickies about asking questions, but, they are closed. Moderator, feel free to move this post.

One of the key things I do in whatever programming system I am engaged in:

Reduce the problem to the smallest reasonable size that demonstrates the problem.

So if you are having issues with cascading combo boxes, build a new application that has a table with 3 fields and one form. Or if your application requires it, two tables and a form and a subform. Do NOT (as another new user with whom I'm engaged in a discussion) include eleventeen tables with half a zillion fields each.

Start with your problem application, make a duplicate, then working with the duplicate rip out chunks until you have ONLY what is needful to demonstrate the problem.

I find that about 1/2 of the time, by doing this, I ripped out the problem too, and the cause of my problem was something entirely different from what I thought it was.

I've also found about a quarter of the time that by the I write up a clear and cogent explanation for what the problem is, I've found the answer before I finished writing, as I checked through all the details one last time as I wrote.

In the last quarter, I ended up with tidy 'hello world' demo of the problem that an experienced programmer could understand in 30 seconds and explain what concept I missed.

On the flip side, when I help (or try to help in my fumble fingered ignorance) someone else, I push for simplicity. I don't like to use his messy tables, but if I understand it, I try to illustrate it as simply as possible.

 

[gemma-the-husky]

one thing that does help, is trying to write small blocks of code, functions and subs that do one thing only. i would pass arguments byref, rather than default byval, (or at least do not change passed in arguments without a specific reason)

avoid over complicated routines with lots of spaghetti programming

use decent error handling.

complicated alogrithms can take time to perfect


much easier to debug such code, and then reuse the code fragments, in a standard code module


I don't think you necessarily need to build a new application to test stuff - you can do most stuff within the app you are developing.

 

[sgbotsford]

I must have mis-spoke. I meant the new app for when you were asking someone for help, or for self use to define exactly what you didn't know.

Pass by reference vs pass by value. There's a case for each. Depending on the language pass by ref can be substantially faster, espcially with large data objects. But the chances of unintended side effects are large. And in many cases you want a permenent change to the underlying object. Doing an update querry by passing a table (Is that possible in Access?) would be silly. The update wouldn't stick.

A friend of mine used an 8 space tab for writing his code. If the indent was large enough to be inconvenient, he abstracted the core out to a new function or subroutine. He also had a line number rule: A proceedure could not be more than 110 lines long -- two pages. If it was, he would usually split it into multiple procedures.

I first learned to program using UCSD Pascal (Now I'm dating myself...) then later Turbo Pascal. Highly recommended for beginning programmers. What some people call, a "Discipline and Bondage" language, because you have to declare absolutely everything, and data types are strongly enforced.

Now, I mostly hack around with perl. Access is a new challenge.

 

[gemma-the-husky]

pascal - me too

the default for passing parameters in VBA is byref.

even if you use byval, most complex structures are still passed byref though.

and as you will know, there is no pointer variable type in VBA.