Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[java] ClassNamingConventions is too ambitious on finding utility classes #1096
Affects PMD Version:
Code Sample demonstrating the issue:
Running PMD through: Gradle
@asarkar thanks for the report. This however seems to not be an issue with PMD itself...
The rule defines properties to allow users to enforce whatever conventions they see fit. You can simply change the value to whatever fits your project and organization very easily:
<rule ref="category/java/codestyle.xml/ClassNamingConventions"> <properties> <property name="utilityClassPattern" value="[A-Z][a-zA-Z]+(Utils?|Helper)"/> <!-- allow *Utils. *Util and *Helper --> </properties> </rule>
We can discuss default values for theses properties, but I would never call draconian a rule that is designed for customization.
@jsotuyod Thanks for your response. I don't think there is an established pattern for what PMD considers utility class. Following are some examples of perfectly acceptable class names that the rule in question would fail:
I understand that I can customize the property, but I shouldn't have to; none of the classnames shown above are out of the ordinary.
I'm of the opinion the utility classname check creates more problems than it solves and should be removed.
I see your point, but I'm not sure to share your opinion.
To remove this just because you personally don't need it seems rather harsh... why should we refrain from letting users enforce a convention if they want to?
You can effectively "disable" this check by setting it to:
<rule ref="category/java/codestyle.xml/ClassNamingConventions"> <properties> <property name="utilityClassPattern" value="[A-Z][a-zA-Z0-9]+"/> </properties> </rule>
I understand you may have an issue with the default values, and we may be open to discuss them (see #1070) but removing functionality is a different matter altogether