Unless there is a particular naming convention that the Pega ruleform suggests (Unit Test Cases should start with TC_) or mandates (Data Pages must start with D_), follow a principle of ensuring a rule is named in a manner that accurately describes its purpose in the application, without reflecting details about how the rule is implemented.
For example, if a When rule determines whether approval is required for an Expense claim, and the requirement is that claims valued more than $100 require approval, name the When rule IsApprovalRequired, not IsExpenseValueGreaterThan100. Inevitably, the approval criteria will evolve over time: the value threshold may change; or additional properties about the Expense Claim become part of the condition.
A rule named based on how it was first implemented can misrepresent its evolving implementation;
A rule named based on what role is plays in the application is entitled to evolve its implementation, and is more reusable.
As for classes, use *-Data-* to represent classes that form the Logical Data Model of your client's applications. Ideally use a distinct class structure (e.g. *-Int-*) for Physical Data Model classes that differ from the Logical Data Model they serve.