Category Archives: Refactoring

Generate, rename and delete getters/setters instantly in Eclipse

Posted on by

Despite the arguments and debates about getters and setters in Java, the fact is that they’re a reality and you have to work with them.

But managing getters and setters is a time-consuming effort. Creating a getter/setter for 5 fields in a class can take minutes, renaming one is error-prone and deleting one is just plain inconvenient.

There are options like Project Lombok (that implicitly creates getters/setters without the need to code them) and you could avoid getters/setters altogether by redesigning your classes.

But these options aren’t always available, so it’s a good thing Eclipse has some handy features for managing getters and setters. Combined with the ability to generate constructors based on fields, you can get the boilerplate code out of the way in seconds and get on with the real coding.

Continue reading →

Convert nested/anonymous classes into top level classes using Eclipse refactoring

Posted on by

Nested classes, eg. anonymous classes, are often more convenient than creating separate classes, especially when working with something like the Command pattern or event listeners. For example:

JButton button = new JButton();
button.addActionListener(new ActionListener() {
    @Override
    public void actionPerformed(ActionEvent e) {
        // ... Do something useful
    }
});

But there comes a point when the nested class becomes so bulky that code becomes unreadable. And sometimes you want to reuse the same class in another place – something that’s difficult with anonymous inner classes.

The answer would be to change the nested class into a top level public class (or a first-class citizen, if you like) that exists in its own file (eg. SomethingUsefulActionListener.java). But doing this manually can take a lot of time and is error-prone.

Eclipse has a couple of refactorings and quick fixes that help to make the job a lot easier. Converting an anonymous inner class to a top level class requires two refactorings only and will take you a couple of seconds instead of minutes. A (named) inner class takes only one refactoring. And passing arguments to the new class is also easy if you use some of Eclipse’s Quick Fixes.

Continue reading →

Get warnings about unused method arguments from Eclipse to keep code clean

Posted on by

Unused variables and methods should alway be unwelcome. Removing them keeps the code cleaner and easier to read. Now, by default Eclipse warns you about unused private variables and methods, but it doesn’t warn you (by default) about unused method arguments.

But there is a compiler setting in Eclipse that can warn you when you don’t use an argument in a method. You can even handle arguments on inherited methods, especially useful when using 3rd party libraries.

Continue reading →

Extract constants from strings and numbers with Eclipse refactorings

Posted on by

For readability’s sake, it’s almost always a good idea to replace magic numbers and string literals with constants. That’s all good, but it can take a bit of time to refactor these to constants, especially strings or parts of strings.

For example, in the code below we want to refactor “shovel and spade” to a private static final String called TOOLS. To do that manually would take some time. It goes even slower if we only want to extract “spade” to a constant because we first have to convert the string to a concatenation.

String tools = "shovel and spade";
...
String otherTools = "shovel and spade";

Luckily, Eclipse has a couple of ways to instantly convert literals to constants. Coupled with tools to speed up string selection and to pick out part of a string, you have the ability to create a constant in about 2 seconds flat. I’ll discuss all these features below.

Continue reading →

Add, remove and reorder a method’s arguments instantly across multiple classes in Eclipse

Posted on by

When refactoring, one thing that sometimes changes is a method’s signature (ie. its return type, number of arguments, argument types and order).

For some it may not happen that often, but the job becomes difficult when you have a dozen or more classes that call that method. All of them need to be changed to match the new signature and this can take a long time to change.

Fortunately, Eclipse has a refactoring called Change Method Signature that makes this easy, allowing a signature change in almost no time across any number of classes. This can be a huge timesaver when you need it and save you hours of frustration trying to fix red crosses in Eclipse.

Continue reading →

Convert string concatenations into StringBuilder or MessageFormat calls with Eclipse’s Quick Fix

Posted on by

Eclipse sports a really nice Quick Fix that turns string concatenations into the recommended calls to StringBuilder. It saves you the time of creating a variable, having to pull out each of the string parts into a call to StringBuilder’s append and then using the string with toString().

So with one key, it will turn code like this:

System.out.println("The year " + year + " is a leap year.");

Into this:

StringBuilder message = new StringBuilder();
message.append("The year ");
message.append(year);
message.append(" is a leap year.");
System.out.println(message.toString());

Continue reading →

Join/split if statements and rearrange expressions using Eclipse Quick Fix

Posted on by

A common cause of bad readability is nested if statements, especially when they could be combined into one if with an AND (&&). This also opens the opportunity to extract private methods to make the if more readable. While you’re at it, you might also want to rearrange the expressions so they make more logical sense.

But making these changes can be tedious and time consuming and often error-prone. It may not happen that frequently, but when it does you want it to go as fast as possible.

Eclipse comes to the rescue with a quick fix that allows you to join or split the statements in one keystroke. And the quick fix allows you to rearrange expressions on the if statement as well.

Continue reading →