An excellent programmer must have standardized and standard coding habits. The following are some suggestions for all programmers who learn Java or other programming languages. 1. The first letter of a class name should usually be capitalized. The first letter of fields, methods, and objects (handles) should be lowercase. As with all identifiers, all words contained within it should be close together, with the first letter of the intervening word capitalized. For example: ThisIsAClassName thisIsMethodOrFieldName If a constant initialization character appears in the definition, capitalize all letters in the static final basic type identifier. This will mark them as compile-time constants. Java packages are a special case: they are all lowercase, even the middle words. For domain name extension names, such as com, org, net or edu, etc., all should be lowercase (this is also one of the differences between Java 1.1 and Java 1.2). 2. When creating a class for general purposes, please adopt the "classic form" and include the definition of the following elements: equals() hashCode() toString() clone() (implement Cloneable) implement Serializable 3. For creating it yourself For each class, consider placing a main() that contains the code for testing that class. To use a class from a project, we don't have to delete the test code. If changes of any kind are made, it is easy to return to testing. The code also serves as an example of how to use classes. 4. The method should be designed into a brief, functional unit, which can be used to describe and implement a discontinuous class interface part. Ideally, the approach should be concise and to the point. If the length is large, consider dividing it into shorter pieces in some way. Doing this also facilitates reuse of code within a class (sometimes, methods must be very large, but they should still only do the same thing). 5. When designing a class, please put yourself in the shoes of the client programmer (the method of using the class should be very clear). Then, put yourself in the shoes of the person managing the code (anticipate what kinds of changes are likely to be made, and think about ways to make them simpler). 6. Make the class as short and concise as possible, and only solve a specific problem. Here are some suggestions for class design: ◆ A complex switch statement: Consider using the "polymorphic" mechanism. ◆ A large number of methods involve operations of widely different types: consider using several classes to implement them separately. ◆ Many member variables have very different characteristics: consider using several classes. 7. Make everything as "private" as possible--private. You can make a certain part of the library "public" (a method, a class, a field, etc.) so that it can never be taken out. If you force it out, it may destroy other people's existing code, forcing them to rewrite and design it. If you only publish what you must publish, you can feel free to change anything else. In multi-threaded environments, privacy is a particularly important factor - only private fields are protected against unsynchronized use. 8. Be wary of "giant object syndrome". For some novices who are accustomed to sequential programming thinking and are new to the OOP field, they often like to write a sequential execution program first, and then embed it in one or two huge objects. According to programming principles, objects should express the concept of the application, not the application itself. 9. If you have to do some unsightly programming, you should at least put the code inside a class. 10. Whenever you find that classes are very closely integrated, you need to consider whether to use internal classes to improve coding and maintenance work. 11. Add comments as carefully as possible and use javadoc comment document syntax to generate your own program documentation. 12. Avoid using "magic numbers", which are difficult to fit well with the code.
If you need to modify it later, it will undoubtedly become a nightmare, because you have no idea whether "100" refers to "array size" or "something else entirely." Therefore, we should create a constant, give it a descriptive and convincing name, and use constant identifiers throughout the program. This makes the program easier to understand and maintain. 13. When it comes to builders and exceptions, you usually want to re-throw any exception caught in the builder if it caused the creation of that object to fail. This way the caller won't continue blindly thinking that the object has been created correctly. 14. After the client programmer has finished using the object, if your class requires any cleanup work, consider placing the cleanup code in a well-defined method, using a name like cleanup() to clearly indicate your use. In addition, a boolean flag can be placed within the class to indicate whether the object has been cleared. In the class's finalize() method, make sure that the object has been cleared and that a class that inherits from RuntimeException has been discarded (if it hasn't already), thus indicating a programming error. Before taking steps like this, make sure finalize() works on your system (you may need to call System.runFinalizersonExit(true) to ensure this behavior).