Skip to main content
    Country/region select      Terms of use
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

woman pumping electricityAs grandfathers tend to do, mine used to tell stories about how tough they had it when he was a kid. "Why, we used to have to pump our own electricity by hand!" he might say, or "We had no TV in those days, so we just had to sit and watch the wall."

Us old-timers who were developing Notes applications before version 6.0 have our own tales to tell. This was before the days of the macro looping functions @For, @Transform, @While, and @DoWhile, and I'm sorry to say, you young whippersnappers have gotten lazy and are using these new functions when there are perfectly adequate ways to do the same thing without them, based on the fact that most operators and @Functions, if you give them a list, will process every element of that list. So for instance, we might see something like this:

result := "";
@For(i := 1; i <= @Elements(TopSet); i := i + 1;
@If(i =1;
result := @Left(TopSet[i]; ":") + " (" + @Text(TopPrice[i]) + ")";
result := result : (@Left(TopSet[i]; ":") + " (" + @Text(TopPrice[i]) + ")")));

The following formula returns the same result, with much less hubbub:

@Left(TopSet; ":") + " (" + @Text(TopPrice) + ")"

If your boss measures your productivity by lines of code, the first formula is obviously better. But for most of us, our managers don't count lines, and are more concerned that we complete our tasks quickly, that our applications work, and that the performance is acceptable. The second formula is a winner in these three areas. It's less typing, it's far easier to debug (my first version of the first formula failed because I forgot about the relative operator precedence of : vs. +). We have to go through the same loop in either case, but the first formula does the loop in an interpreted language, while the second formula loops in fast C code. Even though the second formula actually has to go thru a loop twice (once while processing @Left, and once while processing @Text), it's no contest which is fastest. The second formula is also easier to maintain because it's obvious at a glance what it does -- at least, it is if you know the macro language.

It's true that for those developers who don't understand lists, the second formula may be a little cryptic at first. "Wait! Doesn't it need to loop through all of them?!?" It's important to remember that these are the people we want to punish anyway for not reading the documentation. It will teach them a lesson and maybe their formulas will be more efficient in the future.

Another nifty feature of formula language that people tend to forget about immediately once they've turned past that page in the beginning development class, are the combinatoric operators *+ and *= (there are permuted versions of other operators also, but most of them actually are pretty useless). It's not every day that you need to operate on every combination of a pair of elements from two lists, but sometimes it's nice. For instance, to tell whether the two lists a and b contain any element in common, you could write:

@Keywords(a; b; "") != ""

but it is tres chic to express it as follows (and it also works for non-text lists):

a *= b

Here's a challenge to exercise your list-processing skills. Write a formula that takes the text list Items and produces as output a list where each element is an element of Items preceded by a consecutive number. E.g. if Items = "cow":"horse":"pig" the output of your formula should be "1. cow":"2. horse":"3. pig". Items may contain up to 500 elements, and you may not use @Transform, @For, @While or @DoWhile. Post your answers as comments if you like, but please, readers, try it yourself before you look at other people's answers. The shortest formula wins (note: there is not an actual prize, just prestige). Whitespace doesn't count towards the length.

Andre Guirard | 3 April 2007 07:56:09 PM ET | Plymouth, MN, USA | Comments (42)

Search this blog 


    About IBM Privacy Contact