if (!""==paramString.trim() && paramString.trim().length() > 0 && paramString != null)

I do like to coach colleagues and totally stangers in writing good code. I believe there is also a lot I can learn.
My colleague Thomas tweeted:

unless(!disable_message_hiding) {...}

quad negation. !@#$@# (via @mhevery)

I think I could have done this myself some time ago. You have to learn to avoid negations so this doesn’t pile up like that. I can understand that somebody might have coded that.
But coming back to the line at the beginning of this post:

if (!""==paramString.trim() && paramString.trim().length() > 0 && paramString != null)

How can somebody write this code? Obviously not test driven, because test would have showed that this code is actually mostly nonfunctional.
Ok, when beginning with Java it can happen to you that you check String equality with == and not with String.equals(). Interestingly this does work quite often (but people don’t know why).
trim() shows already some more advanced understanding, because why else would you understand that you want to remove spaces from the string first.
But after having understood that we need to trim() before comparing to empty string, why the additional length check?
And why the hell the not null check? I suspect there was once a stacktrace in the log and this was supposed to fix this. Obviously in reality this method almost never gets null.

So: How could this code have been created? I think the author had no understanding of what he was doing there.

if (paramString.length() > 0)

is code Newbies would write. Its not bad. it is actually covering most of the normal cases. It is almost not worse than the previous example but much easier to read.

Such “empty String” checking is almost in every code. This is why commons-lang provided us with something neat:

if (! StringUtils.isEmpty(paramString))

How do you handle talking about bad code in code reviews? Pair programming?
I found it hard. So i decided to go the way Douglas Crockford goes when he talks about JSlint:

Warning!
JSLint will hurt your feelings.

I say: “that code makes no sense”, “that code is stupid”, “that can be done way shorter”, “code repetition – thats evil”.
It is like the standard measure for code reviews:

WTFs per Minute

WTFs per Minute

I usually try to avoid to call the author stupid. But I try also to be very clear on the code. Usually it helps showing how this can be done much better.
Can somebody recommend a paper or book on the topic?

Oh, in case I did review your code and say something nasty: I apologize. I want to make the code better. I want us all to produce better code. Better code saves us weekends!