Programming Practices

Over time, most developers have adopted practices that help them to write better and more maintainable code. The following are some good rules to start with:

• Keep it simple.
• Keep it readable.
• Build it slowly and test . test , test !
• Document your code. You never know who will have to maintain it later ”it just might be you!

Keeping It Simple

A very wise developer once advised that instead of consuming lots of time trying to write a slick, elegant program, it is better to write one that is simple and that works. Nobody who uses the application ever sees your slick code anyway! Keeping your formulas simple is one way to write code that works.

For example, if you use nested statements in your routine, it can quickly become a nightmare to debug as you add layer after layer of nesting. I am not suggesting that you avoid using nested statements, but it is a good idea to keep them to a minimum. I suggest this for three reasons. First, nested statements are hard to read, even with the ability to format the formula. Second, you cannot comment inside nested formula statements, so even if you format your code, you can't stick a REM statement inside a statement. Third, there is no debugger for the Formula language as we saw in Chapter 12. The deeper the nesting is, the more difficult it is to find bugs .

Keeping It Readable

Keeping your formulas readable is accomplished in two ways. First, use whitespace (blank lines and spaces between operators) and REM statements that describe what your code does. Second, assign statements to temporary variables . For example, consider the following formula:

REM "Get a list of companies from the Lookup view, LUCompanies" ; 
jcCompanyList := @DbColumn(""; ""; LUCompanies; 1) ;

REM "Set up the @Prompt() statement";
DEFAULT jcDefault := cCompanyName ;
jcPromptTitle := "Company Listing";
jcPromptText := "Use the drop-down list button to choose a Company or type in a new entry:

";
REM "Look up the Company Name";
jcCompany := @Prompt([OKCANCELLIST]; jcPromptTitle; jcPromptText; jcDefault;

jcCompanyList);
REM "Store the choice in the cCompanyName field";
FIELD cCompanyName := jcCompany

The previous code has temporary variables, REM statements, and blank lines (whitespace) in the code. The following formula has none and is instead one extremely long complicated line:

FIELD cCompanyName := @Prompt([OKCANCELLIST]; "Company Listing"; "Use the drop-down list

button to choose a Company or type in a new entry:"; @If(@IsAvailable(cCompanyName);

cCompanyName; ""); @DbColumn(""; ""; (LUCompanies); 1))

If you compare this to the previous listing, you will quickly see how much easier it is to read the previous one.

Building It Slowly

In addition, testing debugging in this formula is difficult, at best. If you make a mistake, the formula simply won't work and there will be no indication of where it failed. This is particularly important for the Formula language because you cannot step through the code in a debug mode as you can with LotusScript and many other programming languages. The first version of the formula enables you to test at each step. You can first test the @DBColumn() lookup, and then test the @Prompt() , and then keep moving until you have tested all of it.

Documenting Your Code

You will also notice that the first version of the formula has several REM statements that tell you what the formula is doing at each step. Not only do these statements break up the code visually and make it more readable, but they also provide you and other developers with a guide to what the formula is supposed to accomplish. This can be very important at a later date when you need to modify the formula.