Eleven basic rules for efficient Java programming specifications

The description of Java rules described in this article is divided into five levels. Level 1 is the most basic and important level, and other rules will be written in the future. Following these rules can improve the program efficiency and make the code more readable.

　　(1) avoid using the NEW keyword to create a String object.

Copying a String constant to a String object is usually redundant and time-consuming.

Public class test { Public void method (){ System. out. print (str ); } Private String str = new String ("1"); // It is unnecessary to create a new object. Private String str2 = "2" // this should be the case }

　　 (2) Avoid unnecessary nesting

Excessive 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 in the same row

This will make the program clearer and avoid confusion.

Private int index, index1 [];

The correct method should be as follows:

Private int index; Private int index1 [];

　　 (4) write a statement in each row

This rule does not include for statements, such as: for (int I = 0; I <10; I ++) x --; ', which can increase the readability of the Code.

Public class OSPL { Int method (int a, int B ){ Int I = a + B; return I; // poor readability }

Correct:

Public class OSPLFixed { Int method (int a, int B ){ Int I = a + B; Return I; } }

　　 (5) super. finalize () is often called from finalize ()

Finalize () is called by java during garbage collection, which is different from finally. If your parent class does not define finally (), you should also call it. There are two reasons: (1) You can add the finally method of the parent class to your class without changing the code. (2) In the future, you will get used to calling the finally method of the parent class, even if the parent class does not define the finally method.

The correct method should be as follows:

Public class parentFinalize { Protected void finalize () throws Throwable { Super. finalize (); // FIXED }

　　 (6) do not log off listeners in finalize ().

Do not deregister listeners in the finalize () method. finalize () is called only when no object is referenced. If listeners is removed from the finalize () method, finalize objects will not be removed from garbage collection.

Public void finalize () throws Throwable { BButton. removeActionListener (act ); }

　　 (7) do not explicitly call the finalize () method

Although explicitly calling this method can ensure that you call it, it will be collected again after the 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 by ourselves to do what was initially done by finalize (). Each time you want to explicitly call finalize () the release method is actually called. Then, use a judgment field to make sure that this method is only executed once. It does not 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 APIs that are not recommended

Try to use the APIS recommended by JDK1.3. Many methods in classes, methods, or java components are outdated or optional. Some methods SUN uses the "deprecated" mark. It is best not to use the following example:

Private List t_list = new List (); T_list.addItem (str );

If you check javadoc, we recommend that you use add () instead of addItem ().

　　 (9) create a serialVersionUID for all serialized classes

You can avoid damaging the sequence compatibility from different classes. If you do not specify 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, you cannot deserialize the old version even if the serialized class does not change.

Public class DUID implements java. io. Serializable {public void method (){}}

Add a UID in it. When the serialization form of this class changes, you can also change this UID.

Public class DUIDFixed implements java. io. Serializable { Public void method (){} Private static final long serialVersionUID = 1; }

　　 (10) definition of private Constants

It is better to add the final mark to such a constant, so that the constant will not change from initialization to the final end value.

Private int size = 5;

The changed method is as follows:

Private final int size = 5;

　　 (11) avoid defining local variables and parameters of the method with the same name as class variables.

This can easily cause confusion. We recommend that you define any variable word as unique. In this case, those questions in SCJP won't be used in reality :)

Public void method (int j) {final int I = 5; // VIOLATION} private int j = 2;

Suggestion:

Public void method (int j1) {final int I = 5; // VIOLATION} private int j = 2;