Thanks for the PR!

Could you please add additional test cases in https://github.com/pmd/pmd/blob/master/pmd-apex/src/test/resources/net/sourceforge/pmd/lang/apex/rule/codestyle/xml/ClassNamingConventions.xml See https://docs.pmd-code.org/latest/pmd_userdocs_extending_testing.html for more information about rule testing.

Also I would be interested in:

• Is this common for Apex, that inner classes / interfaces are created?

I wouldn't say that it's a common practice, but it is out there. There are some examples in the official API, but essentially it boils down to organization and consistency. It can also be used to isolate classes that have hidden functionality (although this can be done in other ways, inner classes have the advantage of readability.) One example is Schema.SObjectType. Schema is a class, but so is SObjectType. It just provides organization.

• Can you give an example of the patterns, you would use?

Most recently, a platform cached provider of RecordType objects grouped by Salesforce SObject (meaning database table, essentially an ORM object.) The 'provider/repository' class was the outer class. The classes that applied directly to the object (but inherited from another, separate class) were inner classes.

Although there isn't really any functional benefit to inner classes, they provide organization on a platform that doesn't allow Java-like namespaces in its Apex source code.

...and thanks for allowing me to possibly contribute to this amazing project! I have so many questions for you guys, but I wanted to start with this small offering. The reason is simple: in a project I was working on, we used class names as 'namespace indicators'...a domain prefix if you will. They had a specific standard that was enforced by PMD. Unfortunately, inner classes were being held to the same standard as outer classes and that didn't align with the standard we wanted to follow.

• Can you give an example of the patterns, you would use?

A colleague of mine put it much more succinctly:

In MVC design terminology, it is useful to define an inner class to define the data structure being returned to the view & containing its scope to the controller which interacts with the model. It provides containment/encapsulation.

They had a specific standard that was enforced by PMD. Unfortunately, inner classes were being held to the same standard as outer classes and that didn't align with the standard we wanted to follow.

Now I understand the problem, thanks for clarifying. In that case, adding a separate property for inner class regex is probably the most flexible solution. Another way could be, that inner classes/interfaces are simply not considered by the rule - but then, you won't be able to enforce any naming conventions on them.

They had a specific standard that was enforced by PMD. Unfortunately, inner classes were being held to the same standard as outer classes and that didn't align with the standard we wanted to follow.

Now I understand the problem, thanks for clarifying. In that case, adding a separate property for inner class regex is probably the most flexible solution. Another way could be, that inner classes/interfaces are simply not considered by the rule - but then, you won't be able to enforce any naming conventions on them.

The property solution is definitely the most flexible path. I already implemented it like that because the rule I modified was doing that anyways. I did toy around with one other possibility:

Summit already knows how to make the distinction between inner and outer classes, so why not make inner classes part of the ASTUserClass or ASTUserClassOrInterface object(s)? I tossed those ideas because they seemed too intrusive and I believed that to be a risk to overall design hygiene.

@adangel I am curious about something too, because I frequently find myself buried 'under the hood' of PMD for custom rules. Is there a reason that ANTLR4 isn't a 'strongly suggested' standard for every language? I was looking at different language modules and it seems to be kind of the Wild West.

(FYI: sgnl-labs and justinstroudbah are one and the same person...for whatever reason my initial commit was filed under the account I use for my day job.)

Another point: do we need a separate pattern for inner (nested) enums? And which pattern should be applied for a inner, abstract class? I actually don't want to add too many patterns. So, maybe we can ignore these cases for now until they are really needed?

@adangel Inner enums are actually more common than inner classes. I have an actual use case. We want the outer class to have a specific naming pattern (as traditional namespaces aren't supported, it's kind of a cheat.) However, while we may want that to apply to standalone enums, we do NOT want the 'namespace' to be part of the nested enum name. Does that make sense?

EDIT:
Also, where the enum lives is context-driven. If it applies globally, it should be in a separate file. If it applies to a singular class or whatever, it's an inner enum.

// Class file
public with sharing class Namespace_ThisClass{
  
  // Stuff happens

 enum Days{
   MONDAY,
   TUESDAY,
   // etc.
 }
}

// Standalone enum file
public enum MyNamespace_SomeEnumeratedValues{
 ONE,
 TWO
}

Inner enums are actually more common than inner classes.

So, currently the rule can't distinguish between an outer enum and an inner enum. If this is wanted, a new property is needed. I'd suggest to do this then in a new PR, if needed.

Generated by 🚫 Danger