And one more for you:

Do you use the Assertion framework defined in java language? If so than what for?

I kind of have a problem with this, since the first time I ran into this assertion functionality was way back when only JUnit had this implemented. And I have to admit that it is the most simple and powerful code FOR UNIT TESTING.

Now that we have assert keyword in Java, I still do not see the point of having an assertion in the regular code instead of a simple if statement.

Now let me demonstrate one thing. Which is more readable?

public MyClass(String name) throws  IllegalArgumentException{

   if(name == null){

      throw new IllegalArgumentException("Name cannot be null");

   }
  // the rest of the code

}

or

public MyClass(String name) {

   assert (name != null);

   // the rest of the code

}

Another thing, which of the above examples will imply the  necessity of defining the thrown Exception in the javadoc? That leads to my previous post How Not to Write Java Documentation…

Well, I personally like the first approach (You know I am kind of old fashioned).

As much for the using the Assert (as junit.framework.Assert) class from JUnit framework in a class not belonging to a test case, I only can say: Oh nooooooooo!!!
JUnit is meant ONLY for module testing purpose(at least I like to consider this), and not for regular java code usage.  It is kind of mixing apples with oranges…or something.

And now read the article of Misko Hevery posted on Javalobby: http://java.dzone.com/articles/assert-or-not-assert

Happy coding,

N

Back to “how not to” series.

Today I found a more or less funny article about this topic.

I think that most of us Java developers have spent tons of hours reading badly written javadocs (in the lucky case), and we can tell long stories about these memories.
Even if you consider yourself an experienced developer sometimes you can fall into a trap put by an outdated javadoc comment.

I personally have developed an interesting habit: don’t read javadoc only if it is longer than the autogenerated joavadoc, and instead use JadClipse and decompile the code. It kind of spared me a lot of time. In Eclipse it is very easy to have a class decompiled, so don’t need to leave the IDE, but for those developing in other environment this is also possible using external tools like Front End Plus and others.

One thing is true: badly written code is even worse in a decompiled format, but most of the time for me it was even educative to see different coding approaches.

So my advice, ignore the Javadoc reading in case of too short text and go directly to decompiling of the code.

Read the whole article at http://java.dzone.com/news/how-not-write-java

Happy coding

N