Be expressive, be expressive, b-e e-x-p-r-e-s-s-i-v-e

Code is text. People write it, people read it. It is at it's best when it's clear and accessible. Good code expresses my intentions clearly and concisely. We improve our code all the time by cutting code blocks into smaller, well-named methods, by introducing well-named variables and by other means. Other than reducing the size of the problems handled by each block, we also separate logical concerns. Details of implementation of a certain concern often obfuscate the concern articulation, because they often have to do with other concerns.

Consider the following:

@Reference(WEAK)
private Person client;

public Person getClient() {
return client;
}

public void setClient(Person client) {
this.client = client;
}

I chose a static import for the ReferfenceType.WEAK enum in favor of @WeakRefernce. Contrast it with:

private Reference client;

public Person getClient(Person client) {
if (client != null) {
return client.get();
}
return null;
}

public void setClient(Person client) {
this.client = new WeakReference(client);
}

The client object in both examples serves the exact same purpose. They should be of the same type. The fact that I know enough about this member's life cycle to allow for a certain optimization of memory usage, shouldn't mess my code too much. The compiler can and should fill the required details necessary to make this optimization happen. This would divorce my business logic from this little concern.

This could be achieved with a little bytecode manipulation, but my point is, more should be handed over to the responsibility of the compiler. This is obviously nothing new, but with the introduction of annotations to Java 5, we are given an easy and backward-compatible way of declaring our intentions. More and more technical aspects of our code could be delegated to the compiler if we could define standard ways to define common and repeating intentions. I'll come up with more examples in future posts.