Out of subject : Errare Humanum Est

Basically the implementation look like :

if client => send email to client
if enterprise => send email to client
if others => send email to client

BUT this behavior was not as specified. It should be :

if client => send NO email
if enterprise => send email to enterprise
if others => send email to enterprise

And guess what, it was in production because of ME. Yes, ME. I'm gonna kill myself. How it could be, how I could make such a mistake. By focusing too much on code aspect.

This teach me a great thing. Of course the code aspect, the architecture and so on are important, but the business target IS MORE IMPORTANT than every thing.

Today, I was the stupid guy because Errare Humanum Est.

What time is it ?

// defined previously
// Date aDate = ...

Date date = new Date();
date = new Date(date.getTime());

if (aDate != null && aDate == date) {
    date = new Date(date.getTime() + 10);
}

Hum, the biggest problem with this one is the equality condition test (aDate == date).
In java, == DOESN'T compare value, except for primitive data type, it compares pointer.
That's it, it test if two objects are same. To test if two object are equal (in value) use Object.equals method.


Then, it is trivial that

Date date = new Date();
date = new Date(date.getTime());

is stupid.

Date date = new Date();

is sufficient.

cast it

public static int roundSup(float n){
    int round=0;

    if(n > (new Float(n).intValue()))
    round = new Float(n+1).intValue();
    else round=new Float(n).intValue();

    return round;
}

Sure it needs to create new Float object to do this operation. And the code is ugly.

Try this,

public static int roundSup(
        final float n
) {
    return ((int) n) + 1;
}

Wow ! Cleaner, clearer, better !
Why just a cast will do it ?

See Java Language Specification 3rd : Narrowing Primitive Conversions

But don't forget to COMMENT you're code ! A code without comments it's like a life without meaning.

Program Identifier Naming Conventions

Microsoft 1975 Charles Simonyi's explication of the Hungarian notation identifier naming convention. What to say ? Most people thinks that they need to prefix program identifier (say variable, member...) with the system type. For boolean prefix with 'b' like bDone. For int prefix with 'i' like iCount. That's stupid to be so close to the system type. The thing that is important it's the meaning, count, or index, not the hard system type that can be changed. Let's read these: I’m Hungary Hungarian Notation Cleaner, more elegant, and harder to recognize Dropping the 'I' from interface names?

try surprise me, catch my surprise, finally I'm surprised

public static int doSomething() {
    int i = 0;
    try {
        i = 1;
        System.out.print("a");
        return i;
    }
    catch (Exception e) {
        i = 2;
        System.out.print("b");
        return i;
    }
    finally {
        i = 3;
        System.out.print("c");
        return i;
    }
} // end

return ?

return 3 ! and print "ac".

This code behave like the finally block is an inside method:

public static int doSomething() {
    int i = 0;
    try {
        i = 1;
        System.out.print("a");
        { // finally block
            int another_i = 3;
            System.out.print("c");
            return another_i;
        }
        return i;
    }
    catch (Exception e) {
        i = 2;
        System.out.print("b");
        { // finally block
            int another_i = 3;
            System.out.print("c");
            return another_i;
        }
        return i;
    }
} // end

...
So, and if there is no return in finally block.

public static int doSomething() {
    int i = 0;
    try {
        i = 1;
        System.out.print("a");
        return i;
    }
    catch (Exception e) {
        i = 2;
        System.out.print("b");
        return i;
    }
    finally {
        i = 3;
        System.out.print("c");
        // return i;
    }
} // end

It return 1 and print "ac".
Behave like that:

public static int doSomething() {
    int i = 0;
    try {
        i = 1;
        System.out.print("a");
        { // finally block
            int another_i = 3;
            System.out.print("c");
        }
        return i;
    }
    catch (Exception e) {
        i = 2;
        System.out.print("b");
        { // finally block
            int another_i = 3;
            System.out.print("c");
        }
        return i;
    }
} // end

The try-catch-finally doesn't really behave as first expected.
See Java Hall Of Shame
and finally.

space is too much

/**
 * Return the concatenation of first name and last name separated by a space.
 */
public String getFullname() {
 String s = "";

 if (this.getFirstName() != null) {
  s += this.getFirstName() + " ";
 }

 if (this.getLastName() != null) {
  s += this.getLastName();
 }

 return s;
}

Let's say that firstName = 'Pitt' and lastName = 'Dirk'. We got "Pitt Dirk". And what if the firstName is null, we got " Dirk". Hum, less good.

And what if both are null, we got " ", a space!


This f**king space mess up our database. The better, this kind of method are copied/pasted every where the same behavior was needed.


What do we need then ? A nice join method that concatenate elements of an Object array inserting a separator between elements and ignoring null and/or empty string.

Eclipse 3.3 Europa