Know your JAVA better

Its been years I am working in java and more I work more I love this. Though at times I work on code done by other developers and honestly telling most of the times I just hate their code. I actually met only a few good java developers for whome I can say that they code nice.

I know that if I am saying "I don't like other's code", there must be number of developers like me who don't like my code. I don't disagree with them and yes there must be number of places where I must have done bad coding, I mean nobody is perfect and I accept that fact. Actually sometimes even when I revisit my code I find places where I can improve that and I really do it. In first go my objective always is to make it working with a sufficiently good design and clean code, but yes with time only we realize that we need this and that in application so we need to change our code a bit to make it fulfill the requirements. Once this is done then I revisit my code and make corrections for best design possible and coding as clean as possible.

During all this I have noted down a few points that I keep in mind while coding and I want to share them with everyone. I am sure you will not disagree with all these points. In total there are more than 30 points and explaining them all will take some time so I will just start with a first five of those, I will keep adding new posts.

So here are the initial ones:

• Use standard JAVA patterns: yes, this is simple and a very well known point. Even if I don't point it out here still everyone knows this in their heart. But for the sake of completion and for a buzz word I will say that just go through the patterns and memorize them, they will just appear in your code automatically (if you have understood them well). Actually if you revisit your code after memorizing these patterns, you will see few of them in your code already. This is because few problems have a very standard solution and every developer thinks in same way for those problems. But there are certain problems which can be solved poorly without patterns and in a nice way with patterns, so Memorize Patterns.
• Avoid Object Creation Wisely: There always are number of places where we simply write logs. In our log statements we generally write something like this logger.log("in method abc variable a:"
+a+", b:"+b+", c:"+c); and in general we always wrap logger thing with our custom class but we generally just wrap its methods and thats all, instead if we write some methods like this public void debug(String vals...){

if(!needToDebug)

return;

StringBuilder s=new StringBuilder();

foreach(String t:vals)

s.append(t);

logger.log(s);

}
  This implementation will avoid creation of number of string objects.
• Do not avoid object creation:We all know that JAVA is an Object Oriented Language, but still if we look back at our code we will see that most of the coding that we do is procedural. For example once we get request in controller, we just pass it to next layer that is service layer and then next dao layer. In small apps that works fine but in big complex application we can easily lost in all this. There was a time when object creation used to be considered a bad practice but in new JDK versions object creation is not an overhead. So starting from small application to complex we should develop applications in OOPs way.
• Avoid use of System.: java.lang.System is a utility class and gives number of static methods still we should not exploit them, don't use System.out, or System.currentTimeMillis or System.getPropery. This not only looks bad in code but also sometimes is left in production code. We should use System.getProperty if we need to but that we can do in init code or constructor once only, and even instead of doing this in init or constructor do it somewhere outside and set it as property.
• High Cohesion: If we follow point Do not avoid object creation, high cohesion will automatically start coming in. But that still depends upon the coding. You can find a number of links on high cohesion so I am not going to write much on it.