Java Programming Specification Summary

1. Code general principles

1.1 Common principles that Java programming follows:

• • Clear first. Easy to maintain and easy to refactor.
  • Simplicity is beauty. Easy to understand and easy to implement.
  • Choose the right style for the team to stay consistent.

1.2 also need to pay attention to the aspect:

Object-oriented programming hides a lot of internal implementation details, and when you use many Java features, be careful about using them correctly. For example: Multithreading concurrency, generics, boxing data types, exception handling, object cloning and so on.

　2. Code Style

　　　　Principle 1: Naming principles: Take a good name for packages, classes, methods, variables, and make the code easy to understand.

Principle 2: Prohibition of the use of demon figures
Do not use numbers directly, instead of using meaningful static variables or enumerations.

Principle 3: Constant naming, consisting of all uppercase words, separated by underscores, and using the static final modifier
Principle 4: Variable, attribute naming, using nouns, and using the first-letter lowercase hump naming method
Principle 5: Naming the method, using verbs and the verb-object structure, and using the first-letter lowercase hump naming method

Recommendation 1: To ensure readability, the method name should not be too long
Recommendation 2: Naming the classes and interfaces, using the first-capitalization camel-name method
Recommendation 3: The name of the package, consisting of one or more words, all letters are lowercase
Recommendation 4: Use int[] index when declaring an array, instead of using int index[]

2.2 Notes
Principle 6: Try to explain yourself in code
Rule 1: Comments should interpret the intent of the code, rather than describe how the code is done
Rule 2: Ensure that annotations are consistent with code to avoid misleading
Rule 3: Comments should be adjacent to their description code location, placed above or to the right of the commented code, and indented in the same way as the code
Note: Most comments should be placed above the code, and variables, enumerated annotations can be selected to the right of the Code;
Recommendation 5: In some scenarios, the annotation language is used uniformly in English
Recommendation 6: Do not leave obsolete code with annotations
Recommendation 7: Do not modify the log with comment records
Recommendation 8: General single-line comment with//, block comment with/* */,javadoc comment with/** */
Recommendation 9: The code is simple and clear, try to make the line of code self-explanatory

2.3 Typesetting
Principle 7: The team should adhere to a consistent layout style
Rule 4: Solidify the layout style into the IDE's code format configuration file and let the entire team use
Rule 5: Add a blank line between different concepts
Rule 6: Put logically tightly related code together
Rule 7: Control the width of a line, not more than 120 characters
Rule 8: Minimize the scope of local variables
Declaring a variable at the first use near the variable
Recommendation 10: Add braces {} to the execution body of the IF, for, do, while, switch, etc. statements
Recommendation 11: Control the length of the file, preferably not more than 500 lines

2 variables and Types
Principle 8: Use static member variables with caution
Keep in mind that static variables are variables at the term class level.
Rule 9: Avoid arbitrary type casts, improve design, or use instanceof before conversion
Description: No direct type conversion possible due to a type mismatch
countermeasure: use Instan before casting. Ceof to judge.
The best way to do this is to improve the design so that only objects of the same type are in the collection.　　　　
Rule 10: Do not use float and double
for precise calculations (monetary, financial, etc.), we recommend using int, long, bigdecimal, and so on
Rule 11: Cannot use floating-point number as a loop variable
Rule #:   Floating-point data judgment equality cannot be used directly = =
and should use if (Math.Abs (A-B) < 1e-6f)
Rule 13: Avoid the same local variable before and after the different meaning
one office A part variable should only express one meaning.
Rule 14: Do not assign values to the same variable more than once in a single expression
Recommendation 12: Basic type is better than packing type, pay attention to reasonable use of wrapper type
Basic type is better than packing type, pay attention to use wrapper type appropriately type of scenario With:
1, as an element in a collection, a key and a value of
2, a generic, you must use a wrapper type, such as List<integer>
3, when the method call is reflected

　　　3 methods
Principle 9: The first principle of method design is to be short
The first principle of method design is short, the second principle is also short. Too long a method, difficult to understand and maintain. Short method easy to understand, easy to maintain, easy to expand, easy to test. Based on industry experience, the length of the method is recommended no more than 50 lines.
Principle 10: Method design should follow a single responsibility principle (SRP), a method that accomplishes only one function
Breach of a single duty: 1, multi-segment code to do the same thing repeatedly, then there may be problems in the division of methods, the repetition should be extracted as a method. 2, a method to complete a variety of functions, you should split it into multiple steps of the sub-function.
Principle 11: Method design should follow a single abstract hierarchy principle (SLAP)
Principle 12: Method design should follow the separation principle of command and query responsibility (CQRS)
Rule 15: Do not use the parameters of the method as work variables/temporary variables unless specifically required
Rule 16: Call a static method using the class name instead of using an instance or expression to invoke the
Rule 17 should clearly specify whether the legality of the interface method parameters is checked by the caller or by the interface method itself
Rule 18: The number of parameters of the method should not be excessive
Note: If the parameter is more than 7, it is difficult to maintain, it is recommended to reduce the number of parameters.
If more than one parameter appears in more than one method at a time, the parameters are closely related and can be encapsulated in a class.
Rule 19: Methods for prudent use of variable quantity parameters
　　4 packages, classes, and interfaces

Java Programming Specification Summary