Remove Unused Fields

Description

This rule finds the field declarations that are never used and removes them. Reassignments in the same or in external Java files are not counted as active usages. A configuration wizard allows users to choose whether to remove fields whose initializers may cause side effects (see Configuration). Any annotation except for @Deprecated and @SuppressWarnings prevents the field declaration from being considered as unused.

Avoiding Side Effects

In general, any method or constructor invocation may cause side effects that may be necessary for the correct behavior of the program execution. Therefore, the initializers in field declarations or in the right-hand sides of field reassignments that may cause side effects are preventing the field from being removed by this rule.
Some exceptions are made for some popular Java builtin constructors and methods. For example:

• constructors of collections, maps, sets, and other popular Java classes, e.g., new ArrayList<>(), new HashMap<>(), new Object(), etc...
• methods for retrieving information about a collection without modifying it, e.g., contains(), isEmpty(), size(), lastIndexOf(), etc...
• factory methods for collections, e.g., List.of(), Set.of(), etc...

Benefits

Some benefits of removing unused code, and in particular unused fields, are:

• Reduces maintenance costs.
• Reduces the compilation time.
• May potentially eliminate unnecessary computations for unwanted side effects.

Configuration

This rule, together with Remove Unused Methods and Remove Unused Types, provides a dedicated configuration wizard that allows users to:

• choose which fields to remove based on their access modifier. By default only the private modifier is selected.
• choose the search scope for field references. It can either be set to Project or Workspace.
• choose whether to deliberately remove the fields whose initializers may cause side effects. By default this option is not checked.
  Users are advised to be cautions with this option as the side effects may be necessary for a correct behavior of the program execution.

The following is a shot of the configuration wizard:

When clicking Finish, jSparrow will search for unused fields (as described above), find and analyse their references, and compute the code changes. The changes are shown in a Dif-View and users can choose to accept the computed changes for each field:

Tags

Tags

Java 1.1, Readability, Coding Conventions

Code Changes

Pre

public class UnusedFieldsSample {
	
	public String publicUsedField = "";
	public String publicUnusedReassignedField = "";
	
	private String privateUsedField = "";
	
	void foo() {
		publicUnusedReassignedField = "";
		BlackHole blackHole = new BlackHole();
		blackHole.use(publicUsedField);
		blackHole.use(privateUsedField);
	}
}

Post

public class UnusedFieldsSample {
	
	public String publicUsedField = "";
	
	private String privateUsedField = "";
	
	void foo() {
		BlackHole blackHole = new BlackHole();
		blackHole.use(publicUsedField);
		blackHole.use(privateUsedField);
	}
}

Limitations

At most one field at a time can be removed from the field declarations with multiple declaration fragments.

🛠️ Auto-refactor Available

You can auto refactor this with jSparrow.
Drop this button to your Eclipse IDE workspace to install jSparrow for free:

Need help? Check out our installation guide.

Properties

Property	Value
Rule ID	RemoveUnusedFields
First seen in jSparrow version	4.8.0
Minimum Java version	1.1
Remediation cost	2 min