Modularization is key to reaping the benefits of ILE. It is the major factor in cutting development time and increasing programmer productivity – the more effective the modularization, the more productive the programming staff. But it's important to arm yourself with a reliable method when modularizing your apps.
In part 1,, we discussed the first few tips. Let's now get into the next couple, which will include some code examples.
Keep procedure interfaces simple and pithy
The biggest contributor to a complicated interface (i.e., a long complicated parameter list) is usually a complicated procedure with too many options and permutations. Keep it simple. Don't try to do too much with one procedure. Use multiple procedures instead with each procedure having one or two specific purposes.
For example, don't create a single procedure ConvertCase that converts to uppercase and to lowercase depending on the value of one of the parameters. Instead, create two separate procedures, one to convert strictly to uppercase and the other to convert strictly to lowercase. Not only does this simplify the procedure interface, it also makes the calling programs more readable and self-documenting (instead of seeing ConvertCase, you see either ToUpper or ToLower).
In situations where you have to have a long parameter list, you should consider "packaging" related parameters into a single data structure. This does two things:
1. It shortens the parameter list and makes the procedure interface less complicated.
2. Calls to the procedure will be faster because of fewer parameters.
To simplify using a procedure with a data structure parameter, set up a "template" data structure in an include file (i.e., a /Copy source member), preferably the same one in which you have put the procedure prototype. Then, use the LIKEDS keyword in your program to make a copy of the template data structure for your program to use. This way, the programmer calling the procedure will not have to define the data structure manually. See the sidebar "How to use the LIKEDS keyword" (below) for more information on using the LIKEDS keyword.
It's never too late to modularize
If you see an opportunity to modularize in an existing app, seize it. It is never too late to strip some code out of an existing program and make a separate procedure with it, especially if the code is reusable. Doing so can improve productivity drastically.
Let's look to the April 2007 issue of Inside Version 5 for a perfect example of this. In "Embedded SQL programming without SQL/400 – A working example" (see sqlcli.txt and #sqlcli.txt), we showed you a fairly long program that uses the SQL CLI APIs to achieve embedded SQL. Most of the code is for SQL environment setup and cleanup and is the exact same process any program would have to go through before actually running an SQL statement. This, then, presents a perfect opportunity to modularize after the fact.
First we strip out the setup code and create a procedure called SQLSetup. Then we strip out the cleanup code and put it in a procedure called SQLCleanup. These two procedures, along with the ChkSQLRC procedure, are put into a separate module called SQLCLIXTRA (see sqlclix.txt). To support this module, we either need to add to the previous include file (i.e., #sqlcli.txt) or create a separate one (see #sqlclix.txt).
The same working example program shown last month is now considerably shorter and much easier to read (see sqlcli2.txt). Plus, if coded from scratch, it would have taken much less time.
Keep posted for the rest of the tips next time.
