30 Rules for Java programming

(1) The first letter of the class name should be capitalized. The first letter of the field, method, and object (handle) should be lowercase. For all identifiers, all the words that are contained should be close together and capitalize the first letter of the middle word. For example:

Thisisaclassname

Thisismethodorfieldname

If a constant initialization character appears in the definition, all the letters in the static final base type identifier are capitalized. This will mark the constants that they belong to the compilation period.

Java Packages (Package) are a special case: they are all lowercase letters, even the middle word. For domain name extension names, such as Com,org,net or EDU, all should be lowercase (this is one of the differences between Java 1.1 and Java 1.2).

(2) to create a class for general purposes, take "classic form" and include a definition of the following elements:

Equals ()

Hashcode ()

ToString ()

Clone () (Implement cloneable)

Implement Serializable

(3) For each class you create, consider placing a main () that contains the code to test that class. To use a class in a project, we do not need to delete the test code. If any form of change is made, it is easy to return to the test. The code can also be used as an example of how to use a class.

(4) The method should be designed as a concise, functional unit, using it to describe and implement a discontinuous class interface section. Ideally, the method should be concise. If the length is large, consider dividing it into a shorter method in some way. This also makes it easy to reuse code within the class (sometimes the method must be very large, but they should still do just the same thing). (5) When designing a class, please put yourself in the account of the client programmer (the use of the class should be very clear). Then, put yourself in the hands of the person who manages the code and think about what kind of changes you might want to make, and how you can make them simpler.

(6) Make the class as short as possible and solve only one specific problem. Here are some suggestions for class design:

A complex switch statement: Consider the "multi-form" mechanism

A large number of methods involves the operation of a very different type: Consider using several classes to implement the

Many member variables differ significantly in their characteristics: Consider using several classes.

(7) Make everything as "private"--private as possible. You can make a part of a library "public" (a method, a class, a field, and so on) and never take it out. If forced to take out, it can destroy other people's existing code, so that they have to rewrite and design. If you only publish what you have to announce, you can be confident and bold in changing anything else. Privacy is a particularly important factor in a multithreaded environment-only private fields can be protected in the case of asynchronous use.

(8) The "huge object syndrome". For beginners who are accustomed to sequential programming thinking and early in the field of OOP, they often prefer to write a sequential program and embed it in one or two large objects. According to programming principles, objects should express the concept of an application rather than the application itself.

(9) If you have to do some awkward programming, at least you should put those code inside a class.

(10) Whenever a class is found to be tightly bound to a class, it is necessary to consider whether the internal classes are used to improve coding and maintenance (see "Improving Code with internal classes" in chapter 14th 14.1.2).

(11) Add comments as carefully as possible and generate your own program documentation with Javadoc annotation document syntax.

(12) Avoid the use of "magic numbers", these numbers are very difficult to match the code well. If you need to modify it later, it will undoubtedly become a nightmare, because you simply do not know whether "100" means "array size" or "something completely different". So, we should create a constant, use a persuasive descriptive name for it, and take a constant identifier throughout the program. This makes the program easier to understand and easier to maintain.

(13) When it comes to builders and exceptions, it is often desirable to discard any exceptions caught in the builder-if it causes the creation of that object to fail. This way, the caller does not assume that the object has been created correctly and continues blindly.

(14) When the client programmer finishes using the object, if your class requires any cleanup work, consider putting the purge code in a well-defined way, using a name similar to Cleanup () to clearly indicate your purpose. In addition, you can place a Boolean (Boolean) tag within the class that indicates whether the object has been purged. In the Finalize () method of the class, make sure that the object is cleared and that a class inherited from RuntimeException (if not yet) is discarded, indicating a programming error. Before taking a scenario like this, make sure that Finalize () is able to work on its own system (you may need to call System.runfinalizersonexit (true) to ensure this behavior).

(15) In a specific scope, if an object must be cleared (not handled by the garbage collection mechanism), use the following method: Initialize the object, or, if successful, immediately enter a try block containing the finally clause to begin the cleanup work.