Rules Best Practices
When creating a Rule, setting the correct Context as the first step means that you will have access to the necessary classes and attributes, which will help identify some potential errors.
Rules are intended to work on validating the truth, which is the opposite of query languages. Write to validate what makes an object "correct" rather than to find invalid objects. Searching for truths can find more invalid objects that need processing.
There are many ways to increase performance but it's always better to limit what is being processed. Order Predicates Efficiently to reduce the number of objects being processed helps to speed up each logical section of a Rule (or Action). Start with logic that removes the most objects first to make subsequent logic have fewer objects to process.
When Rules make many complex checks, they are best created as multiple Rules with simple, single purposes, rather than trying to do all checks at once. Separating Rules helps to make reports more specific and more effectively acted on. This also has the benefit of making generic Rules that can be reused in other Sessions.
When iterating over objects, exclude the Root object so that it doesn't compare against itself.
Instead of creating Rules from scratch it's possible to duplicate an existing Rule and make the necessary changes. Alternatively, create or use Rule and Action Templates with the required logic.
Making notes of any changes in the description helps to keep a "paper trail" if something needs reverting or if someone is using the Rule elsewhere.
Readability is an important part of the Rule building process. Adding Comments to Nodes helps to summarise logic, expected outcomes, or any other relevant information. It also allows other users to understand a Rule more easily.
