Code specification (draft)

Unified Universal naming in the team, the general naming needs to accumulate slowly, this cumulative result I call it code specification, code specification can lead the Ascension Program Ape's coding ability.
The areas that are oriented in different teams are very distinct, but the same domain should be named as a professional domain. It also needs to accumulate slowly, and it also belongs to the code specification. But its applicability is not as strong as universal nomenclature.
Code specification = Universal Naming + professional domain naming

General naming is also a professional domain name, if I have to give it a name, I will be named after the "software domain name."
Why is it called Universal naming? Because for the program ape, the Software field is the cornerstone of our existence.
This is where the general word comes from.
All right, no big talk forced. So, I just said that the software domain nomenclature is our favorite. So in our current C-side, I set some rules so that we don't have to worry about defining these things in the future. When you think of a concept, just use a name.
Software Field Reference table:

naming	The concept of expression
Xxxmodule	XXX Module
Xxxmodel	XXX model
Xxxvie	XXX View
Xxxpresenter	XXX main device
Xxxutils	XXX Tool Class (note there s)
Xxxparams	xxx into the Ginseng
Xxxproxy	XXX Agent
Xxxadapter	XXX Adapter
Xxxhelper	XXX Helper
Registry	Registration Form
Xxxevent	XXX Events
Xxxdetail	XXX Details
Xxxlist	XXX List
Xxxmanager	XXX Manager (note there is R)
Xxxservice	XXX Services
Xxxserver	XXX Server
Xxxraw	XXX Inside the
Xxxfacade	XXX Façade
Xxxoperation	XXX operation
Xxxrequest	XXX Request
Xxxresponse	XXX Answer
Xxxfactory	XXX Factory

Our car Superman C-terminal involves the Domain naming reference table:
The concept of named expressions
Carxxx
Orderxxx

Naming principles:
1. Do not expose the implementation
1. The name is meaningful and is named according to the function of the object.
2.

Method naming principle:
1. The method name should explain the internal implementation of the function, but do not pay attention to its details
2. The way to do things as concise as possible single.

Principle 2: Naming to conform to human syntax, that is, using nouns to name "concept" (class name, variable name, local variable name), using a verb phrase to name "behavior" (methods, functions)

Principle 3:

Avoid using magic numbers
Avoid misleading
Avoid using meaningless letters (such as a, B, I ...). ）
Use the unanimously approved, universal naming of the team (such as: generatexxx build xxx, searchxxx search xxx, dosomethingwithxxx what to do with xxx ... ）
Avoid coding (avoid using variable prefixes, suffixes)
Class names should use nouns or noun phrases, avoid using verbs
Method names should be named with verbs or verb phrases
Each abstract concept is chosen as a word, and consistent (the code in the team should not appear to represent a different naming of the same abstract concept, for example, the same means that acquiring this abstraction should not appear in the code the same expression "get" the abstract concept of multiple named Fetch, retrieve, GET, Obtain, etc.)
Multi-use solution domain naming (examples to be perfected)
The separation solution area is named after the name of the problem domain (the name of the problem domain should be used when you encounter code that is closer to the problem area involved)