Ten tips for writing code efficiently

NkD has a theory that nowadays we just assemble parts of frameworks someone else wrote. I agree to a point and don’t find it strange, but I’ve spent an unusual amount of time writing code myself lately. That made me think of sharing a few favorite tips and practices that have worked for me. I don’t want to just repeat Josh Bloch’s Effective Java. If you haven’t read it, I highly recommend it.

1. Null object

Null object, also called Active Nothing, is a design pattern that takes away some of the need to handle null references.

2. Inversion of control and dependency injection

Inversion of control and dependency injection (described here) seem rather controversial among developers. That’s partly because dependencies used to have to be expressed in XML. Modern IoC containers offer other ways, such as annotations. Once you get used to designing APIs this way, it’s hard to give it up.

3. Immutable classes

Immutable classes don’t let you change an instance’s state after initialization. Lukáš Křečan covers them nicely in Immutable Classes. Some classes can’t be immutable, but it’s at least worth thinking about.

4. Program to interfaces

Another point of contention among developers. Everyone exposes java.util.List or java.util.Map in their API instead of an implementation, yet they balk at doing the same for their own classes. I prefer programming to interfaces because it holds up better over time, and it’s paid off for me several times. An interface gives API design more discipline because it keeps you from slipping into implementation details.

5. The open/closed principle

I picked up the combination of protected methods and final public methods from Spring. A class that may be extended defines its behavior through public methods that can’t be overridden. A subclass can override protected methods to extend the parent’s behavior without changing it. That’s exactly in the spirit of the open/closed principle — software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

6. Runtime exceptions

Have you counted how many exceptions in your API actually have to be checked? In most APIs it wasn’t more than 20 percent, with runtime exceptions making up the other 80 percent. I build the exception hierarchy early when creating an API, which avoids unnecessary changes when exceptions get out of hand. A good approach for certain runtime exceptions is the declared runtime exception. And of course there’s the fault barrier.

7. Check method arguments

It hurts, but it works. If you don’t want to write your own checks, try Validate from Jakarta Commons Lang, or Spring’s org.springframework.util.Assert if you don’t mind depending on the Spring API.

8. Don’t repeat yourself

Among other pieces of wisdom, Tomáš Záluský gave me one that now kicks in automatically. If the same code appears in several places, something is wrong and a red light should go on in the programmer’s head. One way to avoid repeating code is described in The Template Method Design Pattern and Its Use in JDBC.

9. Document carefully

When someone tells you well-written code documents itself, there are three things you might think about them.

• They’re joking and want to see how you’ll react
• They’ve never written an API anyone else used
• They’re probably a dilettante or a hopeless optimist

Write Javadoc and comments in the code. Include an example of using the API, or link to a UML diagram. All of this is valuable when you work on a team, and outside one too.

10. Don’t be afraid to refactor

Refactoring is a great way to keep your code from rotting under bad decisions and hacks. It depends to some extent on having tests, unfortunately, though that may be another reason to write them. Besides drastic refactors of half the codebase, make smaller changes such as extracting a method or a local variable. The code will be easier to read and understand.