. NET code specification Learning

I am a relatively free person and do not like to be bound by too many people. Sometimes I do some things and like to do things based on my own ideas. As long as I think it is right, I will stick to it! However, with the continuous development of learning, coding standards make me more and more aware of its importance. To ensure code consistency, the code we write is highly readable and easy to communicate and maintain. More directly, this helps us avoid unnecessary troubles, it brings great economic benefits! Let me talk about it below. NET code specification learning: 1. annotation specification 1. Self-built code file annotation: For self-created code files (such as functions and scripts), the following annotations are generally written at the beginning of the file: /*************************************** * ********* Author: GROUP: Description: creation date: Version: **************************************** * *****/2, standard comment: add comments to the first line of the module, class, attribute, and method so that you are prompted to use the method declaration as an example during the call: // <summary> // depiction: <description> /// </summary> /// <paramname = "<Parameter Name>"> <parameter description> </param> /// <returns >/// <description of the return value of the method, this description must specify the meaning of the returned value >/// </returns> If the module only modifies a small amount of code, The following notes must be added for each modification: // modifier: // Date of modification: <YYYY-MM-DD> // backup: /* original code content */comment out the original code content, and then add the new code with the following comment: // Add person: // Add Date: <YYYY-MM-DD> code content // end: for the restructured class file, you need to back up the original class file, and then put it under the same level directory, add the suffix "_ BAK" after the original file name so that the source code can be sorted out during later version upgrade. 3. comments in code: Comments between codes are divided into single-line comments and multi-line comments: single-line comments: // <single-line comments> multi-line comments: /* multi-line comment 1 multi-line comment 2 multi-line comment 3 */The comments (if, for, foreach,…) must be added when a statement block is encountered in the code ,......), The added comments must be able to describe the functions and implementation methods of this statement block (the algorithms used, the cyclic conditions, the meaning of different branches, and so on ). This is a learning method for adding comments. Adding appropriate comments will make your code as easy to understand as a text. See the second part below. Ii. Naming rules: in general, we need to do this: a. The name should be able to identify the characteristics of things and be linked to the business. B. All names use English words instead of pinyin. C. A name can contain two or three words, but should not contain more than four words. The name must be 3 to 30 letters. D. In a name, multiple words are separated by the first letter (lower case for other letters) in upper case. For example, IsSuperUser. In specific task development, if there are specific naming conventions, the corresponding software development plan should be clearly defined and reported to the Quality Management Department audit team. Point-by-point: 1. Naming generalization: Pascal naming: All the first letters of a word are capitalized, and other letters are lowercase Camel naming: except the first letter, the first letter of other words is capitalized, other lowercase letters include the class name in the class property name, such as Book. bookTitle. Instead, use Book. Title. Use complementary pairs in variable names, such as min/max, begin/end, and open/close. The Boolean variable name should contain Is, which means Yes/No or True/False values, such as fileIsFound. Even for variables that may only have a short lifetime in several lines of code, they still use meaningful names. Only use single-letter variable names for short-cycle indexes, such as I or j. The file name must be the same as the class name. Generally, a file of the next class is named. The file name follows the Pascal naming method. In no special case, the file name extension is in lower case. The unified and common file extension is used: C # class. cs. 2. Abbreviations: to avoid confusion and ensure cross-language interaction: Do not use abbreviations or abbreviations as part of the identifier name. For example, use GetWindow instead of GetWin. Do not use unaccepted abbreviations in the computer field. Replace lengthy phrase names with well-known abbreviations when appropriate. For example, you can use the UI as the abbreviation of User Interface and OLAP as the abbreviation of On-line Analytical Processing. When using the abbreviation, use Pascal or Camel for abbreviations that exceed two characters. However, it should be capitalized with only two characters, for example, System. IO, rather than System. Io. If some words in a name are long, you can write an abbreviated name (the keyword in the name cannot be abbreviated) and make a description file for all the abbreviations, at the beginning of the same level directory. 3. namespace: The general naming rule for a namespace is to use the company name, followed by the technical name and optional functions and designs, as shown below: CompanyName. policyname [. feature] [. design] The namespace is case-insensitive and separated by commas. Policyname refers to the abbreviation of the project, or the software name. The namespace and class cannot use the same name 4, and the class uses Pascal case. Use the full name to avoid abbreviations, unless the abbreviations are already accepted conventions, such as URLs and HTML. For a namespace or folder with long words in the class name, you can abbreviation (the keywords in the name cannot be abbreviated, and other words only take the first letter ), make a description file for all abbreviations and place them at the beginning of the same level directory. Do not use underscores (_). Class name must be known. Data Access Layer: Data Access Layer (DAL) is added after the class name ). Note: There is no DAO concept in. NET. DAO appears in Java, indicating a data access method. Business Logic Layer: BLL (Business Logic Layer) is added after the class name. If the class name is special, you can use the abbreviation, but it should be noted in the document. The full name and meaning of the abbreviation. Interface Layer: webpage-specific classes in asp. You do not need to add a UI prefix or suffix. Entity layer: adds Entity to the end of an object class. If an object class is called as a parameter in other methods, lowercase en is added before the parameter. If the parameter is too long, use the abbreviation, but it should be noted in the document. If the system is large, you should consider grouping classes into different folders to facilitate maintenance and grasp the granularity. 5. Interface: Use Pascal case. Add "I" to the original class name. For example, IUserDao does not use underscores (_). When a class is the standard execution of an interface, similar names are used to define this pair of classes/interfaces. The difference between the two names is that the interface name has an I prefix before it. Or add the suffix "Impl" after the implementation class name. Public interface IComponent {} public class Component: IComponent {} public class ComponentImpl: IComponent {} 6. enumeration (Enum) uses Pascal case for Enum type and value name. The name cannot be abbreviated. The content in the enumeration can be abbreviated. The name cannot be suffixed with Enum. 7. The parameter name can be abbreviated as 8 in Camel case. The method starts with a verb. Use Pascal case. The abbreviation is not allowed unless the term itself contains the abbreviation. For example, AddStudentMgr () 9. attributes are named by nouns or adjectives. Use Pascal case. Disallow abbreviations. 10. The delegate is named after a noun or adjective. Use Pascal case. Disallow abbreviations. If it is associated with an event, the name uses the EventHandler suffix. Otherwise, all other names end with the Delegate suffix. For example, // common delegate defines public delegate void SetMethodDelegate (string name); // delegate and event Association public delegate void MouseEventHandler (objectsender, MouseEventArgs e); 11. Events use Pascal case. Disallow abbreviations. Use the Event suffix for name naming. It is named by a verb or noun and has a time significance, such as the MouseMove event, Closing event, and Closed event. Specify two parameters named sender and e. The sender parameter indicates the object that triggers the event. E is an instance of the event class. E parameter types Use appropriate and specific event classes. Use the EventArgs suffix to name the event parameter class. Example: public delegate void MouseEventHandler (objectsender, MouseEventArgs e); public event MouseEventHandlerMouseEvent; // event definition 12. constants (const) are all capitalized and words are separated. Disallow abbreviations. 13. Use Camel case for private and protected fields. Public is forbidden. 14. static Fields use static fields named after nouns, noun phrases, or abbreviations of nouns. Use Pascal case. 15. The set name must be in the plural. 16. The model uses an uppercase letter (T is recommended) to indicate the class type, and a lowercase letter (such as: t) to indicate the class name. 3. Encoding Rules braces rules: if (expression) (recommended) {} Or: if (expression) {} the indentation rule uses a Tab to indent each layer (four spaces by default, and two spaces are required in some specifications. All ides can be set as required ). Do not enclose parentheses with keywords (such as if and while). Separate them with spaces. For example, if (true) {} Should not enclose parentheses with function names. Do not use parentheses in Return statements unless necessary. Because the keyword is not a function, if the parentheses closely match the function name and keyword, the two are easily regarded as one. A single statement rule only writes one statement per line unless these statements are closely related. Modular rules: If a function is implemented more than once, modularization should be considered and written as a general function. And released to team members. At the same time, try to use the ready-made modules of others. Function complexity rules a single function cannot be too complex and cannot exceed the following limits: the code of a single function sub-function cannot exceed 50 rows, the number of form parameters cannot exceed 7, and the depth of program nesting cannot exceed 7 layers. The complexity of the circle must be less than 15, and the modification or expansion of the program cannot increase the complexity of the original circle. The following style habits must be observed in coding rules: the code is not written, the document goes first, and the annotations must follow the fixed unified paradigm. The relational operation must contain Constants on the left and variables on the right. Complex arithmetic expressions are not allowed. If necessary, brackets are added without priority. The devil's number must be replaced by a macro definition. Local variables must be defined at the beginning to avoid unnecessary memory operations and memory operations must consider exception handling. Version management rules in this project, each task should be packaged and archived after a stable version is completed. The version number of the source code package consists of two numbers separated by dots. The first number indicates the release number, and the second number indicates the revision number of the version. The specific usage is as follows: when the source code package is the first version, the version number is V1.00. When the source code package is partially modified or the bug is corrected, the issue number remains unchanged, and the second number of the Change number increases by 1. For example, if the source code package of the initial version is modified for the first time, the version number is V1.01. When the source code package adds some functions on the original basis, the release number remains unchanged, and the first number of the Change number increases by 1. For example, when some functions are added to V1.12, the new version is V1.20. When the source code package has significant modifications or a large number of partial revisions cause a global change in the source code package, the issue number is increased by 1. For example, if you make a comprehensive modification on the basis of V1.15, the new version number is V2.00. 4. Database naming Rules Database Names Database names should be capitalized to avoid table names retained by the system. For example, the LibraryMaintainSystem database table uses the T _ table name, and the table name uses the first letter in upper case. For example, if the T_Class system is divided into multiple subsystem modules, add the abbreviation of the module to T and separate it with an underscore. Example: Basic System: TB_Class (Basic) Evaluation System: TA _ table name (Assess) Examination System: TE _ table name (Exam) Course Selection System: TC _ table name (Choose) join data table: TR _ Table A Table B, two tables with uppercase letters. One-to-multiple relationship, multiple in front, one in the back. One-to-one and multiple-to-many relationships. The two tables are sorted alphabetically. If the module is divided into modules, the abbreviation of the module is added after T. For example, TBR_ClassGrade indicates the relational table of the basic system, class, and grade. The first letter of a table field is lowercase, followed by a word or pinyin character. The first letter is used in uppercase. The naming rule only comes from the business and expresses the meaning of the column as much as possible. The name is generally a noun or adjective. View view name = V + "_" + name primary key name = PK + "_" + Table name foreign key name = FK + "_" + Table name index name = IDX + "_" + Table name + related fields/index meanings. Association refers to the foreign key relationship association name between database tables = RL + "_" + primary table name + slave table name. Stored Procedure name = PROC + "_" + stored procedure meaning. Trigger trigger name = TR + "_" + Table name + "_" + trigger type/custom name trigger type: Insert trigger plus "_ I ", add "_ D" to the Delete trigger and "_ U" to the Update trigger, for example, TR_Customer_ I, TR_Customer_D, and TR_Customer_U. Finally, let's take a look at the control name specification: