preface

“Alibaba Java development Manual” has been deeply Java development enthusiasts and industry personage’s recognition, which put forward a lot of valuable development experience and suggestions, I believe that we will have a lot of help.

However, it is better to have no book than to have no book. Only after we have our own thinking and recognition of the mentioned norms, can this manual be of greater help to us.

I just want to talk about my understanding of this manual from my personal point of view. I hope it can be updated continuously.

Programming protocol

Naming style

1. [Mandatory] The naming in the code cannot start or end with an underscore or a dollar sign.

Agree, can enforce compliance. First of all, it is possible to do this in actual code development, but it should be the consensus of the industry, and there are no other benefits to starting and ending with the underscore and dollar sign.

2. [Mandatory] All programming related naming is strictly prohibited to use pinyin and English mixed way, not to mention the direct use of Chinese way.

Agree, can enforce compliance. It is easier to understand the definition in pure English, pinyin or pinyin combined with English, but also considering the possibility of polyphonic characters, is not very easy to understand.

3. [Mandatory] Use the UpperCamelCase style for class names, except for DO, BO, DTO, VO, AO, PO, and UID.

Agree, can enforce compliance. Hump naming is basically a consensus, but for DO,BO, etc., in fact, some people like to write BO in the project, some people write BO first, I personally feel that I prefer to use both capitals, these are actually abbreviations of some special terms, so it is appropriate to use both capitals, such as DTO, In fact, it is the abbreviation of Data Transfer Object.

4. [Mandatory] Use lowerCamelCase for method names, parameter names, member variables, and local variables.

Agree, can enforce compliance. It’s basically the industry consensus.

5. [Mandatory] Constant names are all capitalized, words are separated by underscores, and semantic expression is complete and clear, not too long name.

Agree, can enforce compliance. All caps, words separated by underscores, basically all the consensus, I have seen part of the code because of the length of the problem, the use of some abbreviations to express, I personally do not like it, I prefer longer, but prefer more readable developers.

6. 【 Mandatory 】 Abstract class names begin with Abstract or Base. Exception class names end with Exception; A Test class name starts with the name of the class it is testing and ends with Test.

Agree, can enforce compliance. This will make it a little bit clearer.

7. Type and brace next to each other to represent an array.

Agree, can enforce compliance. The counter example mentioned in the manual is to use String args[] as an input parameter to the main function. IDEA is already String[] args when main is automatically generated.

8. [Mandatory] POJO class any Boolean variable, do not prefix is, otherwise part of the framework parsing will cause serialization errors.

The counterexample given in the manual is an attribute defined as the basic data type Boolean isDeleted. The method is also isDeleted(). During the reverse resolution, the framework will assume that the corresponding attribute name isDeleted, causing the attribute to fail to be obtained and thus throwing an exception.

So what frameworks are causing these problems, are there still these problems, are there still historical norms that need to be followed, after all, I think if I add is, if it’s a Boolean type, I’ll understand a little bit better, and I can also match names in the database one by one.

9. [Mandatory] All package names are in lower case, and there is only one natural semantic English word between dot delimiters. The package name is singular, but the class name can be plural.

Partial approval up to the class name can be enforced. The problem with the plural name of a class is that it’s supposed to be a collection of functions and attributes, and as I understand it, it’s not supposed to be plural.

10. [Mandatory] Avoid using identical names between member variables of child and parent classes, or between local variables of different code blocks, which reduces readability.

Basic agreement, can comply with, if it represents the same meaning, with a variable name expression, better readability, management and maintenance is also in a place.

11. [Mandatory] Put an end to completely non-standard abbreviations and avoid looking at the text without knowing the meaning.

Strongly agree. The most afraid code encountered unknown abbreviations, sometimes may not have comments.

12. In order to achieve the goal of self-interpretation of code, any custom programming element should be named with as complete a word combination as possible.

Basically agree, make code self-explanatory, read the variable name to know exactly what it is used for.

13. When naming constants and variables, the nouns denoting types should be placed at the end of words to improve the recognition.

Agree, can enforce compliance. That’s what we do every day.

14. [Recommendation] If modules, interfaces, classes, and methods use design patterns, they should be named to reflect the patterns.

Agree, can enforce compliance. Can reduce the cost of communication, quickly know the specific role.

15. Do not add any modifiers to the methods and properties of the interface class (public also), keep the code concise, and add valid Javadoc comments. Try not to define variables in the interface. If you must define variables, make sure they are related to the interface methods and are fundamental constants for the entire application.

Basically agree. Add public, but the default interface is public, do not add it really can also, interface is generally provided out of the API, must write good comments, otherwise REALLY don’t know how to use this interface. It is true that constants are not defined in the interface, but are maintained by separate constant classes.

16-1. [Mandatory] For Service and DAO classes, based on the SOA philosophy, the exposed Service must be an interface, and the internal implementation class is distinguished from the interface by the Impl suffix.

Agree, can enforce compliance. That’s what we do every day. It’s better to distinguish.

16-2. [Recommended] If the interface name describes the capability, use the corresponding adjective as the interface name (usually – able adjective).

This interface is usually used less, generally declared, represents a bunch of actions, the name is more noun, such as XXXhandler.

17. Enumeration class names are suffixed with enums. Enumerator names must be all uppercase and separated by underscores (_).

Agree, can enforce compliance. That’s how it’s done on a daily basis. It’s a little more readable.

18. Mainly about some naming norms, see the manual for details.

Personal feeling, can refer to below, each group has its own set of norms, do not need to be forced to keep the same as the manual. At present, the persistence layer, the database table is called XXXPO, the presentation object is called VO, the transfer object within the system is called BO, and the data transfer object across the system is called DTO.