Shulou(Shulou.com)06/02 Report--

In this issue, Xiaobian will bring you suggestions on efficiently writing Java code. The article is rich in content and analyzed and described from a professional perspective. After reading this article, I hope you can gain something.

The first letter of the class name should be capitalized. Fields, methods, and objects (handles) should have lowercase initials. For all identifiers, all words contained in them should be placed next to each other and the first letter of the middle word capitalized. For example: ThisIsAClassName thisIsMethodOrFieldName If constant initialization characters appear in the definition, all letters in the static final primitive type identifier are capitalized. This marks them as compile-time constants. Java packages are a special case: they are all lowercase letters, even the middle word. For domain name extensions, 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).

When creating a class for general use, take the "classical form" and include definitions for: equals() hashCode() toString() clone()(implementation Cloneable) implementation Serializable

For each class you create, consider placing a main() that contains code to test that class. To use classes in a project, we don't have to delete test code. If any changes have been made, it is easy to return to the test. This code can also be used as an example of how to use classes.

Methods should be designed as simple, functional units that describe and implement a discrete class interface section. Ideally, methods should be concise. If the length is large, consider splitting it into shorter ones in some way. Doing so also facilitates reuse of code within classes (sometimes methods have to be very large, but they should still only do the same thing).

When designing a class, put yourself in the shoes of the client programmer (the use of the class should be very explicit). Then put yourself in the shoes of the person who manages the code (anticipate what kinds of changes are possible and think about ways to make them easier).

Make classes as short as possible and solve only one specific problem. Here are some suggestions for class design:

A complex switch statement: Consider using a "polymorphic" mechanism.

A large number of methods involve very different types of operations: consider implementing them separately in several classes.

Many member variables differ greatly in their characteristics: consider using several classes.

7. Make everything as private as possible. You can make a part of a library "public"(a method, class, field, etc.), but you can never take it out. Forcing it out could destroy someone else's existing code, forcing them to rewrite and redesign it. If you publish only what you have to publish, you can change anything else with confidence. Privacy is a particularly important factor in a multithreaded environment-only private fields are protected from asynchronous use.

8. Beware of "giant object syndrome." Novices to OOP, accustomed to sequential programming thinking, tend to write a program that executes sequentially and then embeds it in one or two large objects. According to programming principles, objects should express the concept of the application, not the application itself.

If you have to do some unsightly programming, at least put that code inside a class.

Whenever classes are found to be very tightly bound together, consider whether to use inner classes to improve coding and maintenance (see Chapter 14, Section 14.1.2,"Improving Code with Inner Classes").

11, add comments as carefully as possible, and use javadoc annotation document syntax to generate their own program documentation.

Avoid using "magic numbers," which are difficult to match with code. It would be a nightmare to modify it later, because it was never clear whether "100" meant "array size" or "something else entirely." So, we should create a constant, use a convincing descriptive name for it, and use constant identifiers throughout the program. This makes the program easier to understand and easier to maintain.

When it comes to builders and exceptions, it is often desirable to discard any exception caught in the builder if it caused the creation of that object to fail. That way, the caller doesn't blindly continue thinking that the object was created correctly.

When the client programmer runs out of objects, if your class requires any cleanup, consider putting the cleanup code in a well-defined method with a name like cleanup() that clearly indicates its purpose. Alternatively, a boolean flag can be placed inside the class to indicate whether the object has been purged. In the finalize() method of the class, make sure that the object has been purged and that a class inherited from RuntimeException has been discarded (if not already), thereby indicating a programming error. Before taking a scheme like this, make sure finalize() works on your own system (you may need to call System.runFinalizersonExit(true) to ensure this behavior).

If an object must be cleaned up (not by garbage collection) in a particular scope, use the following method: initialize the object; if successful, immediately enter a try block containing a finally clause to begin the cleanup.

The above is what the suggestions for writing Java code efficiently shared by Xiaobian are. If there is a similar doubt, please refer to the above analysis for understanding. If you want to know more about it, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.