Test-drive development is a way to program where you write an automated unit test that fails first, then you write code and check that the test runs ok. Brilliant theory for an ideal world (doesn’t exist). In practice however it is very seldom that you as a programmer have a full and clear understanding of what is it you are gonna do.

Of course I’m not talking about cases where you need to calculate the result of 2+2. Sure you can write a test case here.

And here comes a hard reality where you come to the real place, f.ex. a bank that needs a new program. And here you are with a task that states smth like this “Create a form that have these and these fields and calculates that and that”. You begin with a test case? You are right! That’s what happens if you do this: you kill several days  trying to understand how you build this test case, what fields you need to fill inn to calculate the result. If you’ll try to check a more specific result then you need several extra days to find a person who maybe knows how the value must be calculated.

Because it is very seldom in the real world that programmers work together with persons who both know and can explain to the programmer how the things should be done. Simply because those persons do not exist.

So you wrote the test and now you need to write a calculation algorithm… Hmm, how the hell do we do that? We start building it and magic happens! The algorithm that can calculate the value needs all totally different input values then those you’ve written in your test case… Ouch! It happened again?

At the end you’ve used double time to write the code and update the test case in parallel plus the time you’ve killed on the test at the beginning.

So why is it so popular to talk about it and constantly try to use it? Do not know. You need to write test cases when you program difficult logic. That is the fact. But doing it FIRST? It’s just a waste of time and killing of enthusiasm. You won’t be clever and you’ll not write better code if you kill time with the test first.

What really needs to be done before you start programming is to draw a solution.

No related posts.

No related posts.

Window -> Preferences -> Java -> Editor -> Content Assist -> Advanced ->  check for “Other Java Proposals”

No related posts.

@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,'.')]
           )
     )
]]]>

No related posts.

public Person findPerson() {
   if(someService) [
     return someService.getPerson();
   }
   return null;
}

There is no reason to make a Person object where there are no persons found. But doing so requires extra code in the client to handle the null value. This becomes a problem if a client is, for example, a GUI:

somePage.jsp
<%
  ...
  Person person = myService.findPerson();
%>
<table>
   <tr>
      <td>${person.name}</td>
      <td>${person.address}</td>
      <td>${person.numberOfPurchases}</td>
   </tr>
</table>

The result of such code in cases where the person cannot be found is Server error. So, there is no reason ever to return null from an object-valued method instead of returning an empty object. Especially if you deal with arrays and collections.

No related posts.

public void doSmth() {
    Salary s = calculateSalary(Person p);
    ...
}

private Salary calculateSalary(Person p) {
   return 100;
}

And so we hear from our sjef that we can’t have same salary for male and female. So we do this:

public void doSmth() {
    Salary male = calculateSalary(Person p, true);
    Salary female = calculateSalary(Person p, false);
    ...
}

private Salary calculateSalary(Person p, boolean sex) {
   if(sex) return 100;
   else return 50;
}

Yes, but what if we have more options later on? Or if we look just at the doSmth() function? What do these true/false mean?

An enum type in such cases makes your code easier to read and to write, especially if you are using an IDE that supports autocomplition. Also, it makes it easy to add more options later.

So here’s how we should do it:

public enum Sex {MALE, FEMALE}

public void doSmth() {
    Salary male = calculateSalary(Person p, Sex.MALE);
    Salary female = calculateSalary(Person p, Sex.FEMALE);
    ...
}

private Salary calculateSalary(Person p, Sex sex) {
   if(sex.equals(Sex.MALE) return 100;
   else return 50;
}

No related posts.

• 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();

No related posts.

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();
    }

No related posts.

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.

No related posts.

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.

No related posts.