Dark Views

If you’ve ever developed software for X11, you probably stumbled over “unmap”. For everyone else: If you wanted to make something in a X11 user interface visible, you’d set “unmap” to “false”. A great way to interrupt work because we’re not used to negative thinking. If I want to make something visible, I think “I set some attribute to true” not the other way round.

In Java, we have learned but some API still smells. Collection.isEmpty(), for example. With positive thinking, I think of collections with elements as “better” than one without, so I’d prefer Collection.hasElements() even though it’s longer and boolean properties should use “is” instead of “has”. Oh well. But it’s simple to fall for the negative trap in your daily work as well.

If you find yourself stumble mentally when using a boolean API, refactor and turn it positive. Modern IDEs make this simple and you’ll write more error-free code in less time. commons-lang offers isBlank() and isNotBlank for Strings which is a good example because you don’t have to put a “!” negator in your if’s no matter if blank is good or bad in your specific case and the JIT will inline the code anyway, so there isn’t even a speed penalty (only a LOC penalty).

Even the pros do it: String “constants” i.e. a string literal (that is something between ” quotes) used as a “constant”.

That’s almost as bad as using integer values as arguments instead of defining symbolic names for them! I mean, the values passed into this API are defined by the standard, aren’t they? Sure, you can pass additional feature names as well but that doesn’t stop anyone from defining those which the standard defines somewhere! So what that not all of them must be supported!

There are several reasons why you should always define string constants when your API need strings as parts of it’s “configuration”:

1. It makes it much more simple to find possible values for your API.
2. Auto completion in an IDE is possible and helps to avoid typos.
3. You can add JavaDoc to your strings explaining what they do.
4. Modern IDEs can find out where your strings are being used in the project.
5. You can rename the constant and change the string value, even if you have several constants with the same value!
6. Even if the literals are read from a file, still define a constant for the string and map the raw string to the constant as soon as possible. It makes it so much more simple to track!

Tip: If you still use Java 1.4, define your string constants in an interface (without any other methods). That allows you to use “implements” anywhere where you want to use the constant names without having to prefix them with the name of the interface:

public interface Constants {
    public final static String A = "a";
}

class Demo implements Constants {
    private String value = A;
}

With Java 5, you’ll use enum, of course (especially because you can then use these “strings” in switch statements.

Here is a simple change in your Java development style that will save you a lot of time: When comparing something against a constant, always put the constant first. Examples:

    if (0 == x)...

    public final static String RUN = "run";
    if (RUN.equals (mode))...

That will look strange at first because we’re used to have the constants on the right hand side (from assigns). So what’s the advantage of this? There are three:

1. It will save you a lot of NullPointerException when using equals().
2. It’s more readable in big if/else “switch-alikes”, when you compare a variable against a lot of values.
3. It avoids the accidental assignment as in if (x = 0) (which should have been if (x == 0) … and if you can’t see the difference between the two, you really should always do it this way!) because if (0 = x) generates a compile time error.