11 basic rules for implementing a highly efficient Java programming specification

Programming | Specification The description of the Java rules described in this article is divided into 5 levels, Level 1 is the most basic and important level, in the future will be writing other rules. Following these rules can improve the efficiency of your program, make your code more readable, and so on.

　　 (1) Avoid using the new keyword to create a string object

It is usually superfluous and time-consuming to copy a string constant to a string object.

public class test{
public void Method () {
System.out.print (str);
}
private string str = new String ("1"); The new object here is completely unnecessary.
Private String str2= "2"///the correct should be so
}
　　 (2) Avoid the use of unnecessary nesting

Too much nesting can complicate your code and reduce readability.

public class Test {
String Add () {
Int c= (a=a+b) +b; Too complex
Return C
}
}
　　 (3) Avoid declaring multiple variables of different types on the same line

This will make the program clearer and avoid confusion.

private int index, index1[];
The right thing to be:

private int index;
private int index1[];
　　 (4) Write a statement in each line

This rule does not include a for statement: For example: ' for (int i = 0; i < i++) x--; ' You can increase the readability of your code.

public class Ospl {
int method (int a, int b) {
int i = a + b; return i; Readability is not strong
}
The correct:

public class Osplfixed {
int method (int a, int b) {
int i = a + b;
return i;
}
}
　　 (5) often call Super.finalize () from Finalize ( )

The Finalize () here is called by Java in the garbage collection, and finally different. If your parent class does not define finally (), you should also call. Here are two reasons: (1) You can add the finally method of the parent class to your class without changing the code. (2) Later you will get into the habit of invoking the finally method of the parent class, even if the parent class does not define a finally method.

The right approach should be this:

public class Parentfinalize {
protected void Finalize () throws Throwable {
Super.finalize (); FIXED
}
　　 (6) Do not unregister listeners in Finalize ()

Do not unregister listeners,finalize () in the Finalize () method only if there is no more object reference, and if listeners is removed from the Finalize () method, the Finalize object will not be stripped in garbage collection.

public void Finalize () throws Throwable {
Bbutton.removeactionlistener (ACT);
}
　　 (7) Do not explicitly invoke the Finalize () method

Although explicit invocation of this method allows you to make sure that your call is made, the garbage collection will be collected again when this method is collected.

public class T7 {
public void Finalize () throws Throwable {
Close_resources ();
Super.finalize ();
}
public void Close_resources () {}
}
Class Test {
void Cleanup () throws Throwable {
T71.finalize (); Call
t71 = null;
}
Private t71 = new T7 ();
}
For such a call we should create a release method ourselves, do what was originally finalize (), and actually call the release method each time you want to explicitly call Finalize (). Then use a judgment field to make sure that the method executes only once, and that it doesn't matter if you call it later.

public class T7 {
Public synchronized void release () throws throwable{
if (!_released) {
Close_resources (); Do what the old ' Finalize () '
Did _released = true;
}
}
public void Finalize () throws Throwable {
Release ();
Super.finalize ();
}
public void Close_resources () {}
Private Boolean _released = false;
}
Class Testfixed {
void Closetest () throws Throwable {
t71. Release (); FIXED
t71 = null;
}
Private T7 t71 = new T7 ();
}
　　 (8) Do not use the deprecated API

Try to use the API recommended by JDK1.3. There are many methods in classes and methods or Java components that are stale or optional. There are some ways sun uses the "deprecated" tag. It is best not to use for example:

Private list t_list = new list ();
T_list.additem (str);
If you check Javadoc, you will find that the Add () is recommended instead of AddItem ().

　　 (9) Create a ' serialversionuid ' for all serialized classes

You can avoid the compatibility of sequences that break down from your various different classes. If you don't specifically create a UID, the system automatically generates a UID (based on the content of the class). If the UID changes in your new version of the class, even if the serialized class does not change, you cannot deserialize the old version.

public class DUID implements java.io.Serializable {public void Method () {}}
Add a uid inside, and when the serialized form of the class changes, you can also change the UID.

public class Duidfixed implements Java.io.Serializable {
public void Method () {}
Private static final Long serialversionuid = 1;
}
　　 (10) for the definition of private constants

It is a good practice for such constants, plus the final tag, to not change from initialization to end value.

private int size = 5;
The changing approach is:

Private final int size = 5;
　　 (11) Avoid defining method local variables and parameters with the same name as the class variable

This is easy to cause mixed disturbances, we recommend that any variable words are defined as unique. In this way, the problems in the SCJP are not used in reality:

public void Method (int j) {Final int i = 5;///violation} private int j = 2;
Suggestions:

public void Method (int J1) {final int i = 5;//violation} private int j = 2;