The Eclipse Developer's guide to Clean Code (part 2)

Last time we discussed de-duplicating some code. Today let us look into the effectiveness of refactored code, Java 8 support and moving/renaming code.

But hold on, aren’t method calls expensive?

I took a course on compilers in University and did some research on the matter.
In 1996 Java in-lining might have made sense. But nowadays the overhead that methods generate is relatively negligible, also the JVM is quite smart in optimizing bytecode by in-lining methods that make sense to in-line. Usually the benefits of clarity out-weigh the small constant-time overhead of the method call.

There is an excellent blog post on the matter:

“..method overheads are close to being non-existent. Just 205 ns difference between having 1023 additional method invocations in your source code. Remember, those were nanoseconds (10^-9 s) over there that we used for measurement. So thanks to JIT we can safely neglect most of the overhead introduced by method invocations.” – How expensive is a method call

Move those methods

Sometimes you want to move code around. E.g after extracting helper functions, they might not have the order that you want. Or sometimes when you open a class, you might notice that a public function is not on top of the class (which they should be).

Instead of cut/pasting chunks of code, you can simply drag methods in the method outline and the code will migrate as well:

(As a small note, A-Z ordering needs to be disabled for this to work)

Give variables and methods meaningful names and continue to rename them later.

Ambiguity

If you come across a variable or method that has an ambiguous name, go ahead and rename it.

For example, I’m currently working on a Drag-and-Drop class. The Drag-Source has the following methods, do any look ambiguous?

drag(..)
dragDataDelete(..)
dragEnd(..)
dragGetData(..)

After careful inspection, dragDataDelete() / dragEnd() / dragGetData() were methods that were called when an OS event occurred. However, ‘drag()’ was a method that was called manually from other code, which force-starts a drag operation. This is easily confused with the missing ‘dragBegin()‘ handler that is triggered by an OS event.
Also in order to understand what ‘drag()’ does I have to read all the other methods and compare them, i.e it is not standalone.

If you see this, follow the clean-code rule “Leave the playground cleaner than you left it”. Rename it to something more meaning full such as: dragManualBegin(..). Renaming variables and methods is simple:

Quick rename:
Select method (or variable/class/file) and press Alt+Shift+r, type the new name of the variable and press enter.All references to this method/variable/file are automatically updated:

Rename with preview:Sometimes you may want to see all the places that are affected by renaming. Simply press Alt+Shift+r twice to get a preview plane:

Rename after time

One should really spent some time deciding on how to name a variable. The name should describe the one thing that a function does.
However, the content of the function will often change over time, and as such you should rename the variable/method accordingly.
For example the ‘drag()’ function above was probably the first to have been written, then the others were probably added. After they were added the ‘drag()’ method should really have been renamed to reflect it’s specialization.

Rename works across classes

The rename feature works across your entire project. So if you happen to be in need of renaming a class, go ahead.
This is usually useful for when you’re writing new code as oppose to maintaining older code =)

Eclipse has a lot more refactoring features, but those are the once that I personally use the most.