1. Introduction

Every company and team should have a set of coding specifications, formal or informal. For example, how to name variables, for example, how to write comments?

Then let's say that the coding specification is the agreement of team development habits. The focus is not on a specific detail, but to maintain the unity of style among team members, and the unity of style is the focus. From the perspective of team cooperation, through unified style, the project code written is better readable and easier to maintain and understand among the whole team members; From a personal perspective, consciously abiding by coding norms makes it easier to write high-quality code and improve our personal coding ability.

Today, let's talk about coding specifications and some specific reference conventions.

2. Coding specification

2.1. name

Naming is one of the most important coding standards. To the naming of projects, modules and packages; From the naming of classes, functions, members and variables. A major principle of naming is to express the meaning intuitively. When you see the name, you know the meaning to be expressed without guessing. The specific reference specifications for naming are

[1]The name in the code should not start with: underscore or dollar sign; Do not end with: underscore or dollar sign
	Explanation:
		1.Not a syntax constraint
		2.java Naming conventions in: composed of letters, numbers, underscores and dollar symbols
		3.Cannot start with a number. Everything else is OK
		4.In that case, this constraint can be referred to C++，It is mainly to prevent conflicts with the names in the standard library

[2]For all programming related naming, it is strictly prohibited to use the mixed method of Pinyin and English, let alone Chinese
	Explanation:
		1.Programming common sense, no need to explain
		2.The purpose is to avoid ambiguity and make the code easier to read and understand
		
[3]The class name uses the naming standard of big hump: UpperCamelCase，Exceptions: BO/DTO/VO/PO/UID except
	Explanation:
		1.Programming common sense, no need to explain

[4]Method name, member variable name, parameter name and local variable name use the small hump naming specification: LowerCamelCase
	Explanation:
		1.Programming common sense, no need to explain

[5]Constant names are all capitalized, separated by underscores
	Explanation:
		1.Programming common sense, no need to explain

[6]Abstract class naming Abstract Start and exception class naming Exception At the end, the test class name starts with the target test class and ends with Test End of enumeration class naming Enum The interface name ends with I At the beginning, interface implementation class I Impl ending
	Explanation:
		1.Programming common sense, no need to explain

[7]The array name places the type next to the brackets
	Explanation:
		1.Think of the brackets as part of the type

[8]POJO Member variables in a class are prohibited is As a prefix
	Explanation:
		1.This will cause frame parsing serialization errors
		2.Easy mining pit (the project was launched years ago, and a small partner mined pits on it)
		
[9]Package names are in lowercase and singular form. There is only one English word with natural semantics between dot separators
	Explanation:
		1.Programming common sense, no need to explain
		
[10]Nonstandard abbreviations are prohibited. Common words can be appropriately abbreviated, such as String-->str，Document-->doc，Number-->num
	Explanation:
		1.Look at the text and don't know the meaning
		
[11]If design patterns are used for modules, interfaces, classes and methods, the design pattern identification shall be included in the naming
	Explanation:
		1.Programming common sense, no need to explain

[12]Naming protocol of each layer
	Service/Dao Layer naming method:
		Get a single object: get As a prefix
		Get multiple objects: list As a prefix
		Get statistics: count As a prefix
		Only allow adding: insert As a prefix
		Run updates only: update As a prefix
		Allow adding and updating: save As a prefix
		Delete object: delete As a prefix
	
	Domain model naming:
		Data object: xxDO
		Data transmission object: xxDTO
		Display object: xxVO
		POJO: DO/DTO/BO/VO Collectively

2.2. notes

Writing appropriate comments to the code helps to enhance the understanding of the code implementation logic and enhance readability without guessing. Here we say "appropriate", which means that the more notes, the better. Notes have maintenance costs. For example, if the implementation logic of a method changes due to changes in requirements in the later stage, the annotation on the method needs to be maintained synchronously.

How do we write notes? To sum up, a good comment may contain the following contents:

• What to do? Describe the class and function intuitively

• Why? Visually describe why you need this class and this function. For example, it is necessary to upgrade the old interface capability to a new interface and write why

• How to do it? Describe the main implementation logic in the form of 1, 2 and 3

2.3 Empty line

In the class, different code blocks are isolated to help the readability of the code. For example, between member variables and methods; For example, between different implementation logic blocks within a method.

Make good use of the empty trade, do a little work, but bring full benefits

2.4. indent

Good code indentation is the guarantee to enhance the readability of the code. According to the team habit, we can choose 4 spaces or 2 spaces to indent. However, it should be noted that tab indentation is prohibited

2.5. brackets

Brackets are the identification of our organization's code block, which should follow a unified convention

[1]If the braces are empty, write them succinctly{}Yes, there is no need for line breaks and spaces between braces; If it is a non empty code block:
	1.Do not wrap before left brace
	2.Wrap after left brace
	3.Wrap before closing brace
	4.Right brace followed by else Other codes do not wrap
	
[2]There is no space between the left parenthesis and the adjacent characters on the right; There is no space between the right parenthesis and the adjacent character on the left

2.6. Class, method, code line

Classes, methods, code lines, and how to organize code from different perspectives.

• Class to avoid super large classes. For example, if a class has tens of thousands of lines of code, you need to consider whether the class violates the principle of single responsibility and split it

• Method: in principle, a method should not have too many lines of code. It is recommended to be between 80-100 lines to facilitate the complete display on one screen

• In principle, the length of the code line is controlled at about 120 characters, which is convenient for IDE tools to display one line and avoid too many line breaks

2.7. Class member order

Class members mainly include member variables and methods. It is also divided into static members and ordinary members; From the perspective of scope, it can be divided into public, protected and private. We can refer to the following order of organization members

• Member variables before methods

• First static, then normal

• Large scope first, and then small scope

2.8. nesting

Nesting should not be too deep. In a legacy system reconstruction project years ago, I encountered nearly 20 layers of if Else, I almost didn't slow down at that time. It was very uncomfortable!

Therefore, be sure to remove too deep nesting levels, including

• Remove redundant if or else statements

• Use the keywords continue, break and return to exit nesting in advance

• Adjust the execution order to reduce nesting and abstract some nested logic into functions

2.9. Magic number

It is forbidden to hard code any magic number in the code. Programming common sense, no need to explain, right

2.10. Parameter encapsulation

Avoid too many parameters in methods, especially methods that provide external interface capabilities, such as method(param1,param2,param3,param4,param5,param6...), The consequence of too many parameters is

• Readability and ease of use are not friendly. Adjust a method, pass n multiple parameters, and the code needs to wrap

• The scalability is not good, and the requirements change. What if new parameters need to be added? Modify the interface declaration? Does the caller's client need to change accordingly?

Therefore, the best practice is to encapsulate the parameters through POJO objects.

Finally, the above is the reference of some coding specifications I want to share with you today. I hope to bring some help to you and your team. You need to pay attention to that sentence: the key is to standardize the infinity and unify the style of the whole team.