Download pdf - 10 Commandments for Java Developers

10 Commandments for Java Developers

By Aleksey Shevchenko

There are many standards and best practices for Java Developers out there. Thisarticle outlines ten most basic rules that every developer must adhere to and thedisastrous outcomes that can follow if these rules are not followed.

1. Add comments to your code. Everybody knows this, but somehow forgets tofollow it. How many times have you "forgotten" to add comments? It is true that thecomments do not literally contribute to the functionality of a program. But time andtime again you return to the code that you wrote two weeks ago and, for the life ofyou, you cannot remember what it does! You are lucky if this uncommented code isactually yours. In those cases something may spark your memory. Unfortunatelymost of the time it is somebody else's, and many times the person is no longer withthe company! There is a saying that goes "one hand washes the other." So let's beconsiderate to one another (and ourselves) and add comments to your code.

2. Do not complicate things. I have done it before and I am sure all of youhave. Developers tend to come up with complicated solutions for the simplestproblems. We introduce EJBs into applications that have five users. We implementframeworks that an application just does not need. We add property files, object-oriented solutions, and threads to application that do not require such things. Whydo we do it? Some of us just do not know any better, but some of us do it onpurpose to learn something new, to make it interesting for ourselves. For those whodo not know any better, I recommend reaching out to the more experiencedprogrammers for advice. And to those of us that are willing to complicate the designof an application for personal gains, I suggest being more professional.

3. Keep in Mind "Less is more" is not always better. Code efficiency is agreat thing, but in many situations writing less lines of code does not improve theefficiency of that code. Let me give you a "simple" example:

if(newStatusCode.equals("SD") && (sellOffDate == null ||todayDate.compareTo(sellOffDate)0)) ||(newStatusCode.equals("OBS") && (OBSDate == null ||todayDate.compareTo(OBSDate)

newStatusCode = "NYP";}else if(newStatusCode.equals("OBS") && (OBSDate == null ||todayDate.compareTo(OBSDate)

6. Say no to Print lines and String Concatenations. I know that for debuggingpurposes, developers like to add System.out.println everywhere we see fit. Andwe say to ourselves that we will delete these later. But we often forget to deletethese lines of code or we do not want to delete them. We use System.out.printlnto test, why would we be touching the code after we have tested it? We mightremove a line of code that we actually need! Just so that you do not underestimatethe damage of System.out.println, consider the following code:

public class BadCode{

public static void calculationWithPrint(){

double someValue = 0D;for (int i = 0; i < 10000; i++){

System.out.println(someValue = someValue + i);}

}public static void calculationWithOutPrint(){


someValue = someValue + i;}

}public static void main(String [] n){

BadCode.calculationWithPrint();BadCode.calculationWithOutPrint();

}}

In the figure below, you can observe that method calculationWithOutPrint()takes 0.001204 seconds to run. In comparison, it takes a staggering 10.52 secondsto run the calculationWithPrint() method.

The best way to avoid such CPU waste is to introduce a wrapper method that lookssomething like this:

public class BadCode{

public static final int DEBUG_MODE = 1;public static final int PRODUCTION_MODE = 2;

public static void calculationWithPrint(int logMode){

PDF Creator - PDF4Free v2.0 http://www.pdf4free.com


someValue = someValue + i;myPrintMethod(logMode, someValue);

}}

public static void myPrintMethod(int logMode, double value){

if (logMode > BadCode.DEBUG_MODE){

return;}

System.out.println(value);}

public static void main(String [] n){

BadCode.calculationWithPrint(BadCode.PRODUCTION_MODE);}

}

String concatenation is another CPU waster. Consider example below:

public static void concatenateStrings(String startingString){

for (int i = 0; i < 20; i++){

startingString = startingString + startingString;}

}

public static void concatenateStringsUsingStringBuffer(String startingString)

{StringBuffer sb = new StringBuffer();sb.append(startingString);

for (int i = 0; i < 20; i++){

sb.append(sb.toString());}

}

In the following figure you can see that the method that uses StringBuffer takes.01 seconds to execute where as the methods that use string concatenation takes.08 seconds to execute. The choice is obvious.


7. Pay attention to the GUI. No matter how absurd it sounds; I repeatedlyobserve that GUI is as important to the business clients as functionality andperformance. The GUI is an essential part of a successful application. Very often ITmanagement tends to overlook the importance of GUI. Many organizations savemoney by not hiring web designers who have experience in design of "user-friendly"applications. Java developers have to rely on their own HTML skills and their limitedknowledge in this area. I have seen too many applications that are "computerfriendly" rather then "user friendly". Very rarely I have seen developers that areproficient in both software development and GUI development. If you are thisunlucky Java developer who has been assigned to create an application interface,you should follow these three rules:

1. Do not reinvent the wheel. Look for existing applications that have similarinterface requirements.

2. Create a prototype first. This is a very important step. The clients like to seewhat they are going to get. It is better for you also because you are going toget their input before you go all out and create an application interface thatwill leave the clients cold.

3. Put the user's hat on. In other words, inspect the application requirementsfrom the user's perspective. For example, a summary screen can be createdwith paging and without. As a software developer, it might be temping for youto omit paging from the application because it is so much less complicated.But, from the client's perspective, it might not be the best solution becausethe summary results can hold hundreds of rows of data.

8. Always Prepare Document Requirements. Every business requirement mustbe documented. This could be true in some fairy tale, but it is far from that in thereal world. No matter how time-pressed your development is, no matter how tightthe deadlines, you must always make sure that every business requirement isdocumented.

9. Unit-test. Unit-test. Unit-test. I am not going to go into any details as towhat is the best way to unit-test your code. I am just going to say that that it mustbe done. This is the most basic rule of programming. This is one rule that, above all,cannot be omitted. It would be great if your fellow developer could create andexecute a test plan for your code, but if that is not possible, you must do it yourself.When creating a unit test plan, follow these basic rules:

1. Write the unit test before writing code for class it tests.2. Capture code comments in unit tests.3. Test all the public methods that perform an "interesting" function (that is, not

getters and setters, unless they do their getting and setting in some uniqueway).

10. Remember quality, not quantity. - Do not stay late (when you do not haveto). I understand that sometimes production problems, urgent deadlines, andunexpected events might prevent us from leaving work on time. But, managers donot appreciate and reward their employees because they stay late on regular basis,they appreciate them because they do quality work. If you follow the rules that Ioutline above, you will find yourself producing less buggy and more maintainablecode. That is the most important part of your job.
