sebthom/jstuff

Duplicated Code

Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

Tuning

This issue has a mass of 40.

We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

Refactorings

• Extract Method
• Extract Class
• Form Template Method
• Introduce Null Object
• Pull Up Method
• Pull Up Field
• Substitute Algorithm

Further Reading

• Don't Repeat Yourself on the C2 Wiki
• Duplicated Code on SourceMaking
• Refactoring: Improving the Design of Existing Code by Martin Fowler. Duplicated Code, p76

CollapsibleIfStatements

Since: PMD 3.1

Priority: Medium

Categories: Style

Remediation Points: 50000

Sometimes two consecutive 'if' statements can be consolidated by separating their conditions with a boolean short-circuit operator.

Example:

void bar() {
 if (x) { // original implementation
 if (y) {
 // do stuff
 }
 }
}

void bar() {
 if (x && y) { // optimized implementation
 // do stuff
 }
}

AvoidBranchingStatementAsLastInLoop

Since: PMD 5.0

Priority: Medium High

Categories: Style

Remediation Points: 50000

Using a branching statement as the last part of a loop may be a bug, and/or is confusing. Ensure that the usage is not a bug, or consider using another approach.

Example:

// unusual use of branching statement in a loop
for (int i = 0; i < 10; i++) {
 if (i*i <= 25) {
 continue;
 }
 break;
}

// this makes more sense...
for (int i = 0; i < 10; i++) {
 if (i*i > 25) {
 break;
 }
}

BigIntegerInstantiation

Since: PMD 3.9

Priority: Medium

Categories: Style

Remediation Points: 50000

Don't create instances of already existing BigInteger (BigInteger.ZERO, BigInteger.ONE) and for Java 1.5 onwards, BigInteger.TEN and BigDecimal (BigDecimal.ZERO, BigDecimal.ONE, BigDecimal.TEN)

Example:

BigInteger bi = new BigInteger(1); // reference BigInteger.ONE instead
BigInteger bi2 = new BigInteger('0'); // reference BigInteger.ZERO instead
BigInteger bi3 = new BigInteger(0.0); // reference BigInteger.ZERO instead
BigInteger bi4;
bi4 = new BigInteger(0); // reference BigInteger.ZERO instead

AvoidThreadGroup

Since: PMD 3.6

Priority: Medium

Categories: Style

Remediation Points: 50000

Avoid using java.lang.ThreadGroup; although it is intended to be used in a threaded environment it contains methods that are not thread-safe.

Example:

public class Bar {
 void buz() {
 ThreadGroup tg = new ThreadGroup('My threadgroup');
 tg = new ThreadGroup(tg, 'my thread group');
 tg = Thread.currentThread().getThreadGroup();
 tg = System.getSecurityManager().getThreadGroup();
 }
}

AvoidBranchingStatementAsLastInLoop

Since: PMD 5.0

Priority: Medium High

Categories: Style

Remediation Points: 50000

Using a branching statement as the last part of a loop may be a bug, and/or is confusing. Ensure that the usage is not a bug, or consider using another approach.

Example:

// unusual use of branching statement in a loop
for (int i = 0; i < 10; i++) {
 if (i*i <= 25) {
 continue;
 }
 break;
}

// this makes more sense...
for (int i = 0; i < 10; i++) {
 if (i*i > 25) {
 break;
 }
}

AvoidBranchingStatementAsLastInLoop

Since: PMD 5.0

Priority: Medium High

Categories: Style

Remediation Points: 50000

Using a branching statement as the last part of a loop may be a bug, and/or is confusing. Ensure that the usage is not a bug, or consider using another approach.

Example:

// unusual use of branching statement in a loop
for (int i = 0; i < 10; i++) {
 if (i*i <= 25) {
 continue;
 }
 break;
}

// this makes more sense...
for (int i = 0; i < 10; i++) {
 if (i*i > 25) {
 break;
 }
}

CollapsibleIfStatements

Since: PMD 3.1

Priority: Medium

Categories: Style

Remediation Points: 50000

Sometimes two consecutive 'if' statements can be consolidated by separating their conditions with a boolean short-circuit operator.

Example:

void bar() {
 if (x) { // original implementation
 if (y) {
 // do stuff
 }
 }
}

void bar() {
 if (x && y) { // optimized implementation
 // do stuff
 }
}

AvoidBranchingStatementAsLastInLoop

Since: PMD 5.0

Priority: Medium High

Categories: Style

Remediation Points: 50000

Using a branching statement as the last part of a loop may be a bug, and/or is confusing. Ensure that the usage is not a bug, or consider using another approach.

Example:

// unusual use of branching statement in a loop
for (int i = 0; i < 10; i++) {
 if (i*i <= 25) {
 continue;
 }
 break;
}

// this makes more sense...
for (int i = 0; i < 10; i++) {
 if (i*i > 25) {
 break;
 }
}

AvoidBranchingStatementAsLastInLoop

Since: PMD 5.0

Priority: Medium High

Categories: Style

Remediation Points: 50000

Using a branching statement as the last part of a loop may be a bug, and/or is confusing. Ensure that the usage is not a bug, or consider using another approach.

Example:

// unusual use of branching statement in a loop
for (int i = 0; i < 10; i++) {
 if (i*i <= 25) {
 continue;
 }
 break;
}

// this makes more sense...
for (int i = 0; i < 10; i++) {
 if (i*i > 25) {
 break;
 }
}

AvoidThreadGroup

Since: PMD 3.6

Priority: Medium

Categories: Style

Remediation Points: 50000

Avoid using java.lang.ThreadGroup; although it is intended to be used in a threaded environment it contains methods that are not thread-safe.

Example:

public class Bar {
 void buz() {
 ThreadGroup tg = new ThreadGroup('My threadgroup');
 tg = new ThreadGroup(tg, 'my thread group');
 tg = Thread.currentThread().getThreadGroup();
 tg = System.getSecurityManager().getThreadGroup();
 }
}

AvoidBranchingStatementAsLastInLoop

Since: PMD 5.0

Priority: Medium High

Categories: Style

Remediation Points: 50000

Using a branching statement as the last part of a loop may be a bug, and/or is confusing. Ensure that the usage is not a bug, or consider using another approach.

Example:

// unusual use of branching statement in a loop
for (int i = 0; i < 10; i++) {
 if (i*i <= 25) {
 continue;
 }
 break;
}

// this makes more sense...
for (int i = 0; i < 10; i++) {
 if (i*i > 25) {
 break;
 }
}

CollapsibleIfStatements

Since: PMD 3.1

Priority: Medium

Categories: Style

Remediation Points: 50000

Sometimes two consecutive 'if' statements can be consolidated by separating their conditions with a boolean short-circuit operator.

Example:

void bar() {
 if (x) { // original implementation
 if (y) {
 // do stuff
 }
 }
}

void bar() {
 if (x && y) { // optimized implementation
 // do stuff
 }
}

AvoidBranchingStatementAsLastInLoop

Since: PMD 5.0

Priority: Medium High

Categories: Style

Remediation Points: 50000

Using a branching statement as the last part of a loop may be a bug, and/or is confusing. Ensure that the usage is not a bug, or consider using another approach.

Example:

// unusual use of branching statement in a loop
for (int i = 0; i < 10; i++) {
 if (i*i <= 25) {
 continue;
 }
 break;
}

// this makes more sense...
for (int i = 0; i < 10; i++) {
 if (i*i > 25) {
 break;
 }
}

Overriding or shadowing a variable declared in an outer scope can strongly impact the readability, and therefore the maintainability, of a piece of code. Further, it could lead maintainers to introduce bugs because they think they're using one variable but are really using another.

Noncompliant Code Example

class Foo {
  public int myField;

  public void doSomething() {
    int myField = 0;
    ...
  }
}

See

• CERT, DCL01-C. - Do not reuse variable names in subscopes
• CERT, DCL51-J. - Do not shadow or obscure identifiers in subscopes

Fields in a Serializable class must themselves be either Serializable or transient even if the class is never explicitly serialized or deserialized. For instance, under load, most J2EE application frameworks flush objects to disk, and an allegedly Serializable object with non-transient, non-serializable data members could cause program crashes, and open the door to attackers. In general a Serializable class is expected to fulfil its contract and not have an unexpected behaviour when an instance is serialized.

This rule raises an issue on non-Serializable fields, and on collection fields when they are not private (because they could be assigned non-Serializable values externally), and when they are assigned non-Serializable types within the class.

Noncompliant Code Example

public class Address {
  //...
}

public class Person implements Serializable {
  private static final long serialVersionUID = 1905122041950251207L;

  private String name;
  private Address address;  // Noncompliant; Address isn't serializable
}

Compliant Solution

public class Address implements Serializable {
  private static final long serialVersionUID = 2405172041950251807L;
}

public class Person implements Serializable {
  private static final long serialVersionUID = 1905122041950251207L;

  private String name;
  private Address address;
}

Exceptions

The alternative to making all members serializable or transient is to implement special methods which take on the responsibility of properly serializing and de-serializing the object. This rule ignores classes which implement the following methods:

 private void writeObject(java.io.ObjectOutputStream out)
     throws IOException
 private void readObject(java.io.ObjectInputStream in)
     throws IOException, ClassNotFoundException;

See

• MITRE, CWE-594 - Saving Unserializable Objects to Disk
• Oracle Java 6, Serializable
• Oracle Java 7, Serializable

Early classes of the Java API, such as Vector, Hashtable and StringBuffer, were synchronized to make them thread-safe. Unfortunately, synchronization has a big negative impact on performance, even when using these collections from a single thread.

It is better to use their new unsynchronized replacements:

• ArrayList or LinkedList instead of Vector
• Deque instead of Stack
• HashMap instead of Hashtable
• StringBuilder instead of StringBuffer

Even when used in synchronized context, you should think twice before using it, since it's usage can be tricky. If you are confident the usage is legitimate, you can safely ignore this warning.

Noncompliant Code Example

Vector cats = new Vector();

Compliant Solution

ArrayList cats = new ArrayList();

Exceptions

Use of those synchronized classes is ignored in the signatures of overriding methods.

@Override
public Vector getCats() {...}

Unused parameters are misleading. Whatever the values passed to such parameters, the behavior will be the same.

Noncompliant Code Example

void doSomething(int a, int b) {     // "b" is unused
  compute(a);
}

Compliant Solution

void doSomething(int a) {
  compute(a);
}

Exceptions

The rule will not raise issues for unused parameters:

• that are annotated with @javax.enterprise.event.Observes
• in overrides and implementation methods
• in interface default methods
• in non-private methods that only throw or that have empty bodies
• in annotated methods, unless the annotation is @SuppressWarning("unchecked") or @SuppressWarning("rawtypes"), in which case the annotation will be ignored
• in overridable methods (non-final, or not member of a final class, non-static, non-private), if the parameter is documented with a proper javadoc.

@Override
void doSomething(int a, int b) {     // no issue reported on b
  compute(a);
}

public void foo(String s) {
  // designed to be extended but noop in standard case
}

protected void bar(String s) {
  //open-closed principle
}

public void qix(String s) {
  throw new UnsupportedOperationException("This method should be implemented in subclasses");
}

/**
 * @param s This string may be use for further computation in overriding classes
 */
protected void foobar(int a, String s) { // no issue, method is overridable and unused parameter has proper javadoc
  compute(a);
}

See

• CERT, MSC12-C. - Detect and remove code that has no effect or is never executed

Fields in a Serializable class must themselves be either Serializable or transient even if the class is never explicitly serialized or deserialized. For instance, under load, most J2EE application frameworks flush objects to disk, and an allegedly Serializable object with non-transient, non-serializable data members could cause program crashes, and open the door to attackers. In general a Serializable class is expected to fulfil its contract and not have an unexpected behaviour when an instance is serialized.

This rule raises an issue on non-Serializable fields, and on collection fields when they are not private (because they could be assigned non-Serializable values externally), and when they are assigned non-Serializable types within the class.

Noncompliant Code Example

public class Address {
  //...
}

public class Person implements Serializable {
  private static final long serialVersionUID = 1905122041950251207L;

  private String name;
  private Address address;  // Noncompliant; Address isn't serializable
}

Compliant Solution

public class Address implements Serializable {
  private static final long serialVersionUID = 2405172041950251807L;
}

public class Person implements Serializable {
  private static final long serialVersionUID = 1905122041950251207L;

  private String name;
  private Address address;
}

Exceptions

The alternative to making all members serializable or transient is to implement special methods which take on the responsibility of properly serializing and de-serializing the object. This rule ignores classes which implement the following methods:

 private void writeObject(java.io.ObjectOutputStream out)
     throws IOException
 private void readObject(java.io.ObjectInputStream in)
     throws IOException, ClassNotFoundException;

See

• MITRE, CWE-594 - Saving Unserializable Objects to Disk
• Oracle Java 6, Serializable
• Oracle Java 7, Serializable

Fields in a Serializable class must themselves be either Serializable or transient even if the class is never explicitly serialized or deserialized. For instance, under load, most J2EE application frameworks flush objects to disk, and an allegedly Serializable object with non-transient, non-serializable data members could cause program crashes, and open the door to attackers. In general a Serializable class is expected to fulfil its contract and not have an unexpected behaviour when an instance is serialized.

This rule raises an issue on non-Serializable fields, and on collection fields when they are not private (because they could be assigned non-Serializable values externally), and when they are assigned non-Serializable types within the class.

Noncompliant Code Example

public class Address {
  //...
}

public class Person implements Serializable {
  private static final long serialVersionUID = 1905122041950251207L;

  private String name;
  private Address address;  // Noncompliant; Address isn't serializable
}

Compliant Solution

public class Address implements Serializable {
  private static final long serialVersionUID = 2405172041950251807L;
}

public class Person implements Serializable {
  private static final long serialVersionUID = 1905122041950251207L;

  private String name;
  private Address address;
}

Exceptions

The alternative to making all members serializable or transient is to implement special methods which take on the responsibility of properly serializing and de-serializing the object. This rule ignores classes which implement the following methods:

 private void writeObject(java.io.ObjectOutputStream out)
     throws IOException
 private void readObject(java.io.ObjectInputStream in)
     throws IOException, ClassNotFoundException;

See

• MITRE, CWE-594 - Saving Unserializable Objects to Disk
• Oracle Java 6, Serializable
• Oracle Java 7, Serializable