Rule Naming Best Practices
What your thoughts/opinions on the following?
In OO code development there are best practices for naming things whether called attributes (properties in Pega) or methods (rules in Pega).
Anything that returns a boolean (TrueFalse) for example should sound like a question, e.g., IsBla.
A rule should also reflect whether it is generic or specific.
Ask yourself, does the rule belong at the enterprise layer or is it specific to an application or even specific to a case type?
It is fine to define a generic-sounding rule if it is expected to be overridden as rules in the inheritance path specialize (inheritance is an OO requirement).
You do not want to name a rule too generically when the implementation only does one specific thing.
The consumer of the rule would be fooled into thinking the rule does what it says when in reality it only works in certain situations.
A rule should also not be named too specifically.
A rule should not give away what it encapsulates (encapsulation is an OO requirement).
A rule does not need to say what properties it uses internally – StartDate for example.
Similar to Java methods accepting arguments, a rule accepts parameters.
As opposed to StartDateIsFuture you would define a When rule named IsFuture that accepts a DateTime parameter.
A rule name should also not say how it does something as that may be subject to change.
What your thoughts/opinions on the following?
In OO code development there are best practices for naming things whether called attributes (properties in Pega) or methods (rules in Pega).
Anything that returns a boolean (TrueFalse) for example should sound like a question, e.g., IsBla.
A rule should also reflect whether it is generic or specific.
Ask yourself, does the rule belong at the enterprise layer or is it specific to an application or even specific to a case type?
It is fine to define a generic-sounding rule if it is expected to be overridden as rules in the inheritance path specialize (inheritance is an OO requirement).
You do not want to name a rule too generically when the implementation only does one specific thing.
The consumer of the rule would be fooled into thinking the rule does what it says when in reality it only works in certain situations.
A rule should also not be named too specifically.
A rule should not give away what it encapsulates (encapsulation is an OO requirement).
A rule does not need to say what properties it uses internally – StartDate for example.
Similar to Java methods accepting arguments, a rule accepts parameters.
As opposed to StartDateIsFuture you would define a When rule named IsFuture that accepts a DateTime parameter.
A rule name should also not say how it does something as that may be subject to change.
A rule name should indicate its “contract”, i.e., what “service” it provides.
This follows the Open/Closed Principle.
Once you define a rule and have consumers, if you change the rule dramatically, such as adding required parameter, you impact all of the rule’s consumers.
The whole idea of OO programming is to avoid “ripple effects”.
You will not get anywhere if you keep having to revert back to changing code that is a consumer/client of other code.