Those who use hibernate for database access know that you need to provide an information that this object is a hibernate object. To do so you typically need to annotate your object with @Entity. It’s not a problem although if we speak about some large system. In large systems we have typically a number of instances of the same object that represent the same table in different contexts and packages. And here we need this: to give each object unique name.
Example:

@Entity(name="person.usa")
class Person {
   ...
}

This PMD rule shows how to check if a hibernate object have a name.

<![CDATA[
     //Annotation/NormalAnnotation[
     (
           Name/@Image='Entity'
           and
           not
           (
                 MemberValuePairs/MemberValuePair/@Image='name'
                 and
                 //PrimaryExpression/PrimaryPrefix[contains(Literal/@Image,'.')]
           )
     )
]]]>

I’ve recently come to a heuristic called the Law of Demeter (LoD) or Principle of Least Knowledge that says a module should not know about the innards of the objects it manipulates. More precisely, the method of a particular class should call:

• other methods of the same class
• objects created by the method itself
• objects passed as arguments to the method
• objects held in an instance variable of the same class

And that”s all!

So the following code appears to violate the Law:

String output = obj.getContext().getOptions().getDir().getPath();

It’s easy to forget something around such a structure. This one can solve the issue:

String output = obj.getPathFromContext();

1. Use the == to check if the argument is a reference to this object.

2. Use the instanceof operator to check if the argument has the correct type.

3. Cast the argument to the correct type.

4. For each “significant” field in the class, check if that field of the argument matches the corresponding field of this object.

5. Always override hashCode when you override equals.

6. Don’t substitute another type for Object in the equals declaration.

7. Write unit-test.

   @Override
   public boolean equals(Object obj) {
      if(obj == this) {
         return true;
      }
      if(!(obj instanceof Person)) {
          return false;
      }
      Person p = (Person)obj;
      return p.name.equals(name)
             p.birthday.equals(birthday)
             p.personNumber == personNumber;
      }

Ref.”Effective Java” by Joshua Bloch

Enother example with hashCode and toString:

    @Override
    public boolean equals(Object obj) {
        if (obj == null || !obj.getClass().isInstance(this)) {
            return false;
        }
        Beregning b = (Beregning) obj;

        return new EqualsBuilder()
                .append(simulertPensjon, b.getSimulertPensjon())
                .append(linjer.size(), b.getLinjer().size()).isEquals();
    }

    @Override
    public int hashCode() {
        return new HashCodeBuilder().append(simulertPensjon).append(linjer).hashCode();
    }

    @Override
    public String toString() {
        return new ToStringBuilder(this, ToStringStyle.SHORT_PREFIX_STYLE)
        .append("simulertPensjon", simulertPensjon)
        .append("antall linjer", linjer.size()).toString();
    }

The book by Robert C. Martin “Clean Code” is a really very useful material for all programmers. You can disagree with him sometimes (as I do), but it still provides some useful notes that helped me to place my programmer experience and knowledge where they belong. Here I’ll provide some key notes that I did while reading the book and that I’d like to memorize.

What you as a programmer SHOULD DO:

1. Give everything meaningful, searchable and pronounceable names.
2. Use names that other programmers can understand. Remember that the code is for programmers, not customers.
3. Functions should be small and smaller than that.
4. Functions should do one thing. They should do it well. They should do it only.
5. The ideal number of arguments for a function is zero. Max 3.
6. Prefer exceptions to returning error codes. Create informative error messages.
7. Prefer meaningful names to comments.
8. Write JavaDoc only for public API’s.
9. Format your code. While working in a team use a single formatting style.
10. Test your code with clean tests. Remember that test code is just as important as production code.
11. Test just one concept per test.
12. Test should follow the FIRST rule:

Fast -  tests should be fast.
Independent - tests should not depend on each other
Repeatable - tests should be repeatable in any environment
Self-validating – the test should have a boolean output
Timely - write unit tests before the production code.

What you as a programmer should AVOID:
1. Avoid encoding
2. Avoid duplicate code. Watch out not only duplicate functions but also duplicate functionality.
3. Avoid noisy, redundant, uninformative comments. Remember that one of the more common motivations for writing comments is bad code.

Here is a very useful java conversion table that I’ve created while preparing for the Sun Certified Java Programmer exam.

Java primitive conversions table

And here is a complete overview of the Golden rules of widening, boxing & varargs:

1. Primitive Widening > Boxing > Varargs.
2. Widening and Boxing (WB) not allowed.
3. Boxing and Widening (BW) allowed.
4. While overloading Widening + vararg and boxing + vararg are mutually exclusive of each other.
5. Widening between wrapper classes not allowed
6. Widening+varArgs & Boxing+varargs are individually allowed (but not allowed in overloaded version of method)
7. Boxing+Widening is preferred over Boxing+Varargs.

More explanation here.