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.

Use a Java Refactoring Tool

No license required

You can review this refactoring on your code without a license by installing jSparrow to your Eclipse IDE. Install the plug-in from Eclipse IDE: Eclipse Marketplace.

System-wide Refactoring

Do you want to automate this refactoring (and many more) to your system-wide code? The automatic application of this system-wide refactoring can be unlocked by acquiring your jSparrow license.

Properties

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