[TABLE]
Make sure you always use "Option Declare." It sounds obvious, but there are several determining factors as to why you should always use it. Here are some of the reasons:
[TABLE]
When working with templates and versions in LotusScript in custom code, there are a few things you should always do:
You might say these all sound like good reasons, but why should I use them? There are three major reasons:
[TABLE]
When dealing with the lifecycles of your applications, there are a few best practices you should follow:
Here is why you should adhere to these rules:
[TABLE]
Here are the fundamental how's and why's of how to code in LotusScript:
Here is why you should follow these LotusScript how-to coding guidelines:
[TABLE]
"Measure twice, cut one" may sound a bit cliche, but it is a good analogy when you are writing LotusScript code. Here are a couple ways it applies.
This works well because you are spending more time planning and less time doing actual labor.
[TABLE]
You should always try to use "ubound" to establish the size of your array. Below you will find an example of it in use.
If you set up your arrays this way, you won't need to keep a separate index of the array size; it also automatically trims the code. However, there is a minor drawback to implementing this. It will slow down large arrays, so you'll need to define the "empty" value. Otherwise, it works great.
[TABLE]
When you use the list operator, it stores a value with a unique lookup key. It's a good idea to use the list operator because:
Here is some example code:
[TABLE]
Another good tip is to log your LotusScript agents, especially i
To continue reading for free, register below or login
To read more you must become a member of SearchDomino.com
');
// -->

f they are scheduled agents. It's also a good idea if you have a broad range of clients. If you do, you need to log both your client and scheduled agents runtime status.
If you don't log your agents, chances are that your applications will break. Logging your agents will also help to let you know when your LotusScript agents do break. It's also a good timing metric for performance testing.
Show caution when logging your agents though -- you don't want to make the logging so slow that it affects application performance!
[TABLE]
When dealing with the structure of your LotusScript code, it is usually good to keep it as short as possible. Smaller code sequences are easier to deal with and maintain and are easily reusable. A good rule to go by is if your code is more than a screen's worth, you should determine if it is possible to break it up.
Some tips when determining your LotusScript code structure:
[TABLE]
When we say we're "hiding our code," we're basically saying that we're decomposing it so consumers can't see it. You don't want anyone to be able to view it, not even yourself.
When you hide your code, you are inferring a logical interface with clear naming. As such, your users and customers can write to the interface but not the code itself. This is good practice because it simplifies the coding experience.
You can easily hide your code by using "private/public" methods in your classes, script libraries, etc.
[IMAGE]
[IMAGE]TUTORIAL: 30 LOTUSSCRIPT TIPS
[IMAGE]
[IMAGE] Home: Introduction
[IMAGE] Part 1: 10 fundamental LotusScript tips
[IMAGE] Part 2: 10 everyday LotusScript tips
[IMAGE] Part 3: 10 advanced LotusScript tips
[IMAGE] Part 4: More LotusScript learning resources