Skip to main content

Clayton Rules -Naming conventions on Apex inner classes

David Martin avatar
Written by David Martin
Updated this week

Rationale

Consistent naming conventions are fundamental to developing robust and easily maintainable Salesforce applications. For Apex inner classes, this consistency is even more critical as they often define the internal structure and relationships within a larger class. By enforcing a standardized naming scheme, we significantly:

  • Improve Code Readability: Developers can quickly infer the purpose and context of an inner class simply by its name, reducing cognitive load and speeding up comprehension.

  • Enhance Maintainability: A predictable codebase simplifies debugging, refactoring, and feature development, as developers spend less time deciphering unfamiliar naming patterns.

  • Facilitate Onboarding: New team members can more rapidly understand the project's structure and contribute effectively when consistent patterns are followed.

  • Reduce Errors: Clearer code naturally leads to fewer misinterpretations and, consequently, fewer bugs.

This rule helps ensure that all Apex inner classes adhere to a predefined organizational standard, contributing to a more coherent and professional codebase.


Scope

This rule is strictly applied to Apex inner classes. This includes classes defined within other Apex classes, whether they are private, protected, public, global, static, or non-static.
​

Configurations

  • Pattern. Use a regular expression to define the validation pattern for your class names.

  • Hint. Add a hint to be displayed when a detection is flagged, in order to give developers a tangible example of a name that suits naming convention. (Warning: the hint is not validated, make sure it matches your validation pattern before adding it).

Exclusions

This rule is designed to focus on production and application-specific code. Therefore, it does not apply to test classes. Inner classes defined within Apex test classes (classes annotated with @IsTest) will not trigger a violation for this rule. This exemption prevents unnecessary warnings on utility classes often found within test contexts, which may follow slightly different internal naming practices.

Did this answer your question?