I’ve been asked to convert an application at work. Its not huge (5800 lines), but its just tons of (VB3) if’s and else’s and nested if’s and else’s. Some of the conditions are based on String comparions (ie State = “DE”) or ranges (balance < 200), etc.
As part of the conversion I really wanna not only get all the decisioning code organized, but pull it out into a database so that existing rules can be more easily managed and new rules can be incorporated without re writing the system everytime the business changes.
Any ideas on where to begin or maybe a seminal paper that can help me get going?
My blood shot eyes thank you, what’s left of my brain thanks you, and I thank you…
Seems a little vague and genral of a question. Maybe with more info about what the data is, where it comes from, and what the app does with it, we could be of more help. Knowing what you’re converting it to could also help, if that language happens to have any nifty specific features.
But as is, your question is basically a very general how do I write good code'', so my answer will be a general step away from the computer. Grab pencil and paper. Draw the data structures. Flowchart the application’s functions.’’
I’ve done one of two things in this situation depending on the structure of the decisions made.
If the decisions can be factored into categories, for example, the decisions are all based on a state, several sets of number ranges, and some other criteria, I would attempt to write the program so that it was table driven. The database would be that table, there would be an editor component to edit the contents of the table, and the programs execution would essentially consist of the interpretation of that table. On the extreme edge of this approach, you may have to add an additional parameter that indicates that in this particular state, ignore certain parameters, etc. It all hinges on whether the data in the table can be factored such that the program is really executing the table’s contents. The optimal situation is when each row of the database is the decision criteria for that item, the solution breaks down as the data begins to contain more control information.
If the decisions are a big series of related decisions, then you might consider an Expert System engine. One good example is called CLIPS. It comes in DLL form, I think it’s accessible from VB. CLIPS is essentially the software that executes the rules, you write the rules in the little language used by CLIPS, but the rest is done for you. CLIPS is free and can be found on the web, along with great tutorials, and stuff.
In which case, the answer is probably a fairly straightforward database solution, where the relevant variables are looked up in a database table. A decent intro to databases will shed enough light on the problem to answer it. It is not uncommon to find hard coded values entered into a program in a way that uses a program as a database; it sounds like this might be the case here.
If it is a case of doing something different depending on the value, that is
If ( lpState==’CA’ && nBalanace < 200 )
WriteStrongLetter()
If (lpState==’CA’ && nBalanace > 200 )
WriteReallyStrongLetter()
Try reading about the design theory behind n-tier architecture, specifically about stuff that involves “separating implementation from business rules”. It has been a few years since I had to do this (and, as it turned out, didn’t have to do this anyway, but had to learn a little about it), but that was one of the uses of n-tier architecture. It might be over kill, or it might be extremely useful in cutting maintenance time. Good luck either way.
Let me know if this helps; it is possible that with a little more information I might have more specific recommendations for you. I apologize if I am completely off base with my guesses about what you are trying to do.
Don’t know anything about VB3, but it sounds like you need to categorize the conditions into some kind of structure and put the conditions in a database table. One column for the case (i.e. the condition that the row applies to) and another column with a codified list of actions to be done.
You then construct a loop that steps through the table (or only a part of the table if you’ve structured it correctly) testing each case.
The strength of this method really relies on the interface to the table. Does the person adding or editing the rows in the table need to be a programmer or can you interprete things into a more natural language? If they need to be a programmer then you need to consider if you’ve not achieved anything other than added an additional layer of complexity to your application.
A good example to look at would be email filtering conditions on most email applications.
My co-worker ended up snagging a project like that. (Pity the intern. Actually, I was the under-intern… pity me!) He did manage to get almost everything working (it was a report generator, IIRC), but then needed a bunch of comparisons later to fix the bugs that made it through. When he was doing it, the other possibilities were either to:
-Don’t convert the program, write a whole new one, with user input for requirements, instead of reverse engineering some icky code.
-At least find out what the heck the thing is doing. Then you might understand why it’s asking if (balance > 200), and be prepared for any associated pitfalls.
You could try writing a parser that reads each source file, and grabs IFs and SELECT CASE statements from the code, along with perhaps the name of the subroutine that contains them and the nesting level (if the original code is reliably nested).
Long time since I’ve used VB3; I think there’s an option to save the source as compressed binary files, which, if it’s been used for your source code, means you’ll have difficulty parsing it. However, you can save all the files off (perhaps to a separate location) as non-binary files, and then they’ll be simple text files and can be parsed.
If you don’t know any good parsing languages, you can write a VB program to do the job, using DIR$ to search a directory for source files, text file input to read the files, and VB’s string-handling routines (e.g. INSTR$, MID$) to find the patterns you want; in fact it’ll probably be easier to tailor a VB program to your needs, e.g. writing the results to your database.
I sympathise. A long time ago I had to convert a COBOL program which had a main routine that, when printed out, was 13 pages long, littered with GOTOs. A nasty task, but character-building
Good luck!
All good advice so far. Since this is a conversion you might consider just leaving the logic as-is and translating the VB3 code to whatever you converting it to. This assumes that (a) the code currently works, and (b) that the language you are converting it to has a fairly close coding style to VB3.
The downside of leaving the logic alone is that new rules may be more difficult to implement, so you need to find out just how often that happens.
I myself would hate to do it this way, but it may be the most practical approach.
Universal rule of business related programming. If the logic is too convoluted to follow and looks a mess it usually means you’re going about it the wrong way. Far better to junk the whole lot and consider the problem again from scratch.
And there’s nothing worse than a conversion that’s following rules that no-one understands the logic behind. It’s waste of time doing the convertion and makes comprehensive documentation impossible from the word go. Any official company audit of the system would also draw a big red box around the whole thing.
I’d say that screeds of “else ifs” is a fair sign of a program that needs broken down and redesigned from the ground up.
What you mention is a very good guildline, but sometimes guidelines should be broken. It depends on just how critical this application is, how bad the programming backlog is, how often the rules for the application change, etc.
I’m not necessarily recommending this approach as much as I am offering it for consideration. There are too many unknowns right now for anyone to give a hard and fast recommendation.
It might be best to have a look up table (be a text file, ISAM or other database) that way you can have the rules (and change them) without a recompile. The file might be set up like this
state balance_low balance_high fine
DE 0 200 23
DE 201 400 37
DE 401 9999999 45
WI 0 350 21
WI 351 720 48
...
Then just one algorithm that reads and handles the data.
I guess this is pretty much what others are saying.
True, but if you are coding for something something illogical (US tax code) or complicated (hyphanation rules for ISBNs), not much you can do about it.
Thanks all. I’ve haven’t decided how to handle it yet, but at least knowing that others have suffered the same is heart-warming. I looked at CLIPS and did some research on some other Rules/Expert Systems, but since my company is in the dark ages I think I’m stuck just rewriting the thing in VB6 and just moving on.
