Data Classes are simple data holders, which reveal most of their state, and without complex functionality. The lack of functionality may indicate that their behaviour is defined elsewhere, which is a sign of poor data-behaviour proximity. By directly exposing their internals, Data Classes break encapsulation, and therefore reduce the system's maintainability and understandability. Moreover, classes tend to strongly rely on their data representation, which makes for a brittle design. Refactoring a Data Class should focus on restoring a good data-behaviour proximity. In most cases, that means moving the operations defined on the data back into the class. In some other cases it may make sense to remove entirely the class and move the data into the former client classes. The rule uses metrics to implement its detection strategy. The violation message gives information about the values of these metrics: * WMC: a class complexity measure for a class, see {% jdoc java::lang.java.metrics.JavaMetrics#WEIGHED_METHOD_COUNT %} * WOC: a 'non-triviality' measure for a class, see {% jdoc java::lang.java.metrics.JavaMetrics#WEIGHT_OF_CLASS %} * NOPA: number of public attributes, see {% jdoc java::lang.java.metrics.JavaMetrics#NUMBER_OF_PUBLIC_FIELDS %} * NOAM: number of public accessor methods, see {% jdoc java::lang.java.metrics.JavaMetrics#NUMBER_OF_ACCESSORS %} The rule identifies a god class by looking for classes which have all of the following properties: * High NOPA + NOAM * Low WOC * Low WMC <pre> <code> public class DataClass { // class exposes public attributes public String name = &quot;&quot;; public int bar = 0; public int na = 0; private int bee = 0; // and private ones through getters public void setBee(int n) { bee = n; } } </code> </pre> <a href="https://docs.pmd-code.org/pmd-doc-7.19.0/pmd_rules_java_design.html#dataclass"> See PMD documentation. </a>

Avoid using hard-coded literals in conditional statements. By declaring them as static variables or private members with descriptive names maintainability is enhanced. By default, the literals "-1" and "0" are ignored. More exceptions can be defined with the property "ignoreMagicNumbers". The rule doesn't consider deeper expressions by default, but this can be enabled via the property `ignoreExpressions`. With this property set to false, if-conditions like `i == 1 + 5` are reported as well. Note that in that case, the property ignoreMagicNumbers is not taken into account, if there are multiple literals involved in such an expression. <pre> <code> private static final int MAX_NUMBER_OF_REQUESTS = 10; public void checkRequests() { if (i == 10) { // magic number, buried in a method doSomething(); } if (i == MAX_NUMBER_OF_REQUESTS) { // preferred approach doSomething(); } if (aString.indexOf(&#x27;.&#x27;) != -1) {} // magic number -1, by default ignored if (aString.indexOf(&#x27;.&#x27;) &gt;= 0) { } // alternative approach if (aDouble &gt; 0.0) {} // magic number 0.0 if (aDouble &gt;= Double.MIN_VALUE) {} // preferred approach // with rule property &quot;ignoreExpressions&quot; set to &quot;false&quot; if (i == pos + 5) {} // violation: magic number 5 within an (additive) expression if (i == pos + SUFFIX_LENGTH) {} // preferred approach if (i == 5 &amp;&amp; &quot;none&quot;.equals(aString)) {} // 2 violations: magic number 5 and literal &quot;none&quot; } </code> </pre> <a href="https://docs.pmd-code.org/pmd-doc-7.19.0/pmd_rules_java_errorprone.html#avoidliteralsinifcondition"> See PMD documentation. </a>