##### Overview

- Download PMD 5.0.4
- What's new in PMD 5.0.4
- PMD in the news
- PMD-related products and books
- Best practices
- Future directions
- Similar projects
- Credits
- License
- What does 'PMD' mean?

##### Usage

- Installation
- Command line usage
- Ant task usage
- Maven plugin usage
- Mvn plugin usage
- IDE plugin usage
- Suppressing warnings
- Finding duplicated code
- JSP support

##### Customizing PMD

- Compiling PMD
- How to write a rule
- Writing XPath rules
- How to make a rule set
- How it works
- Rule guidelines
- PMD developers information
- PMD Release Process

##### For example

- Run PMD on a Sourceforge project

##### Misc.

- XPath tutorial (Gregorian)

##### Rule Sets

- ecmascript
  - Basic Ecmascript
  - Braces
  - Unnecessary
- java
  - Android
  - Basic
  - Braces
  - Clone Implementation
  - Code Size
  - Comments
  - Controversial
  - Coupling
  - Design
  - Empty Code
  - Finalizer
  - Import Statements
  - J2EE
  - JavaBeans
  - JUnit
  - Jakarta Commons Logging
  - Java Logging
  - Migration
  - Naming
  - Optimization
  - Strict Exceptions
  - String and StringBuffer
  - Security Code Guidelines
  - Type Resolution
  - Unnecessary
  - Unused Code
- jsp
  - Basic JSF
  - Basic JSP
- xml
  - Basic XML
- xsl
  - XPath in XSL

##### Project Documentation

- Project Information
- Project Reports

## Coupling

Rules which find instances of high or inappropriate coupling between objects and packages.

### CouplingBetweenObjects

Since: PMD 1.04

This rule counts the number of unique attributes, local variables, and return types within an object. A number higher than the specified threshold can indicate a high degree of coupling.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.coupling.CouplingBetweenObjectsRule

Example(s):

    import com.Blah;
    import org.Bar;
    import org.Bardo;

    public class Foo {
       private Blah var1;
       private Bar var2;

     	//followed by many imports of unique objects
       void ObjectC doWork() {
         Bardo var55;
         ObjectA var44;
         ObjectZ var93;
         return something;
       }
    }

This rule has the following properties:

Name | Default Value | Description
violationSuppressRegex |  | Suppress violations with messages matching a regular expression
violationSuppressXPath |  | Suppress violations on nodes which match a given relative XPath expression.
threshold | 20 | Unique type reporting threshold

### ExcessiveImports

Since: PMD 1.04

A high number of imports can indicate a high degree of coupling within an object. This rule counts the number of unique imports and reports a violation if the count is above the user-specified threshold.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.coupling.ExcessiveImportsRule

Example(s):

    import blah.blah.Baz;
    import blah.blah.Bif;
    // 18 others from the same package elided
    public class Foo {
     public void doWork() {}
    }

This rule has the following properties:

Name | Default Value | Description
violationSuppressRegex |  | Suppress violations with messages matching a regular expression
violationSuppressXPath |  | Suppress violations on nodes which match a given relative XPath expression.
topscore |  | Top score value
minimum | 30.0 | Minimum reporting threshold
sigma |  | Sigma value

### LooseCoupling

Since: PMD 0.7

The use of implementation types as object references limits your ability to use alternate implementations in the future as requirements change. Whenever available, referencing objects by their interface types provides much more flexibility.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.coupling.LooseCouplingRule

Example(s):

    	// sub-optimal approach
    private ArrayList list = new ArrayList();

    public HashSet getFoo() {
    	return new HashSet();
    }

    	// preferred approach
    private List list = new ArrayList();

    public Set getFoo() {
    	return new HashSet();
    }

This rule has the following properties:

Name | Default Value | Description
violationSuppressRegex |  | Suppress violations with messages matching a regular expression
violationSuppressXPath |  | Suppress violations on nodes which match a given relative XPath expression.

### LoosePackageCoupling

Since: PMD 5.0

Avoid using classes from the configured package hierarchy outside of the package hierarchy, except when using one of the configured allowed classes.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.coupling.LoosePackageCouplingRule

Example(s):

    package some.package;

    import some.other.package.subpackage.subsubpackage.DontUseThisClass;

    public class Bar {
       DontUseThisClass boo = new DontUseThisClass();
    }

This rule has the following properties:

Name | Default Value | Description
violationSuppressRegex |  | Suppress violations with messages matching a regular expression
violationSuppressXPath |  | Suppress violations on nodes which match a given relative XPath expression.
classes | [] | Allowed classes
packages | [] | Restricted packages

### LawOfDemeter

Since: PMD 5.0

The Law of Demeter is a simple rule, that says "only talk to friends". It helps to reduce coupling between classes or objects. See also the references: Andrew Hunt, David Thomas, and Ward Cunningham. The Pragmatic Programmer. From Journeyman to Master. Addison-Wesley Longman, Amsterdam, October 1999.; K.J. Lieberherr and I.M. Holland. Assuring good style for object-oriented programs. Software, IEEE, 6(5):38–48, 1989.; http://www.ccs.neu.edu/home/lieber/LoD.html; http://en.wikipedia.org/wiki/Law_of_Demeter

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.coupling.LawOfDemeterRule

Example(s):

    public class Foo {
        /**
         * This example will result in two violations.
         */
        public void example(Bar b) {
            // this method call is ok, as b is a parameter of "example"
            C c = b.getC();

            // this method call is a violation, as we are using c, which we got from B.
            // We should ask b directly instead, e.g. "b.doItOnC();"
            c.doIt();

            // this is also a violation, just expressed differently as a method chain without temporary variables.
            b.getC().doIt();

            // a constructor call, not a method call.
            D d = new D();
            // this method call is ok, because we have create the new instance of D locally.
            d.doSomethingElse();
        }
    }

This rule has the following properties:

Name | Default Value | Description
violationSuppressRegex |  | Suppress violations with messages matching a regular expression
violationSuppressXPath |  | Suppress violations on nodes which match a given relative XPath expression.