Code compiling specification (C #. NET and Asp.net)

Code compiling specification (C #. NET and Asp.net) Contents 1 Purpose Range 2 3. annotation Specification 3.1 Overview 3.2 user-created code file comments 3.3 Module (class) Comment 3.4 class attribute comments 3.5 method comments 3.6 comments between codes 4. Naming rules 5. Naming rules 5.1 variable (variable) Name 5.2 constant name 5.3 class naming 5.4 interface naming 5.5 Method naming 5.6 namespace) Name 6 encoding rules 6.1 error check rules 6.2 braces 6.3 indent rules 6.4 parentheses 6.5 if then else rules 6.6 comparison rules 6.7 case rules 6.8 alignment rules 6.9 single statement rules 6.10 single function rules 6.11 simple function rules 6.12 clear conditions and rules 6.13 select the false rule 6.14 independent assignment rules 6.15 define constant rules 6.16 modular rules 6.17 communication rules 7 programming principles 7.1 variable usage 7.2 database operations 7.3 object usage 7.4 Module Design Principles 7.5 structured requirements 7.6 function return value principle 8. code package specification 8.1 version number of the code package 8.2 code package ID 9 code control 9.1 create a code library/directory 9.2 code Archiving 10 input control validation rules 10.1 login Control 10.2 Data Entry Control Appendix 1: abbreviated data type table Appendix 2: Server Control name abbreviations   1 Purpose I. to unify the programming specifications of the company's software development and design process 2. Enable website developers to easily understand the meaning of each directory, variable, control, class, and method. 3. program coding specifications established to ensure that all programming programs comply with the same standards and ensure consistency and uniformity. 4. coding specifications and conventions must significantly improve code readability and help code management and classification scope to apply to all enterprise software development work based on. NET platforms. Range 2 This specification applies to all developers who act on the coding and post-maintenance phases of software project development. 3. annotation Specification 3.1 Overview A) The comments must contain punctuation marks in English and English. B) The complete name and purpose of the object should be indicated in the annotation, but too detailed descriptions of the Code should be avoided. C) The maximum length of each line comment is 100 characters. D) Separate the comment and comment separator with a space. E) do not add an external box to the comment. F) write comments while coding. G) important variables must be annotated. H) for variable comments and variables on the same line, all comments must be aligned and separated by at least four "spaces" keys. For example, int m_ilevel, m_icount; // m_ilevel... tree level // M_icount... count of tree items String m_strsql; // SQL I) typical algorithms must have annotations. J) comments must be written nearby in the uplink of the loop and logical branch. K) comment a program segment or statement on the previous line of the program segment or statement. L) temporary or irrelevant comments must be deleted before code delivery. M) to facilitate reading the code, the length of each line of code should be less than 100 characters. 3.2 user-created code file comments For self-created code files (such as functions and scripts), write the following comments at the beginning of the file: /*************************************** *************** Filename: Copyright (c) 2004-xxxx ********** Technology Development Department of the company Writer: Create Date: Rewriter: Rewrite Date: Impact: Main Content (function name, parameters, returns) **************************************** **************/ 3.3 Module (class) Comment Module comments must be written in the following form at the beginning: /// <Summary> /// Module ID: <module ID, which can reference the module ID in system design> /// Depiction: <the description of this class, which can be referenced in the system design> /// Author: Chinese name of the author /// Create Date: <module creation date, format: YYYY-MM-DD> /// </Summary> If the module only modifies a small amount of code, the following notes must be added for each modification: /// Rewriter rewrite Date: <modify Date: Format YYYY-MM-DD> start1: /* Original code content */ /// End1: Comment out the content of the original code and add the new code with the following comments: // Added by add Date: <add date, format: YYYY-MM-DD> start2: /// End2: If the input/output parameters or function structure of a module are greatly modified, the following notes must be added for each modification: /// <Summary> /// Log ID: <log number, which is added once from 1> /// Depiction: <description of the change> /// Writer: the modifier's Chinese name /// Rewrite Date: <module modification date, format: YYYY-MM-DD> /// </Summary> 3.4 class attribute comments Attribute comments must be written in the following format for class attributes: /// <Summary> /// <Properties depiction> /// </Summary> 3.5 method comments Annotations must be written in the following format before the class method declaration /// <Summary> /// Depiction: <description of this method> /// </Summary> /// <Param name = "<Parameter Name>"> <parameter description> </param> /// <Returns> /// <Description of the return value of the method, which must specify the meaning of the returned value> /// </Returns> /// Writer: the author's Chinese name /// Create Date: <method creation date, format: YYYY-MM-DD> 3.6 comments between codes Comments between codes can be divided into single-line comments and multi-line comments: // <Single line comment> /* Multi-line comment 1 Multi-line comment 2 Multi-line comment 3 */ You must add comments (if, for, foreach,…) when encountering statement blocks in the code ,......), The added comments must be able to describe the functions and implementation methods of this statement block (the algorithms used, and so on ). 4. Naming rules The name should be able to identify the characteristics of things. All names use English words instead of pinyin. Do not use abbreviations unless they are well known. A name may consist of two or three words, but should not contain more than three words. The name must be 3 to 30 letters. In a name, multiple words are separated by the first letter in upper case (lower case for other letters. For example, issuperuser. Try to use a prefix instead of a suffix for the name. The words in the name should use nouns whenever possible. If there are verbs, try to put them behind them. For example, functionuserdelete (instead of functiondeleteuser ). 5. Naming rules 5.1 variable (variable) Name A) variable name in the program file (*. CS) In the program, the variable name = the prefix of the variable + the English word or word abbreviation that represents the meaning of the variable. For Class module-level variables, use "M _" + Data Type abbreviation as the prefix (where M is the abbreviation of "Memory, for the abbreviation of data type, see the data type abbreviation table in the attachment). Public class hello { Private string m_strname; Private datetime m_dtdate; } The variable corresponding to the class property, in the form of "M _" + type abbreviation prefix before the property name Public class hello { Private string m_strname; Public string name { Get { Return m_strname; } } } Process-level variables use prefix of abbreviated type Public class hello { Void say () { String strsayword; } } The process parameters use the "P _" + type abbreviation as the prefix (where, p is the "parameter" abbreviation) Public class hello { Void say (string p_strsayword) { } }   Note: Naming exception variables during exception capture is the same as exp without conflict; If there is a conflict, you can use the "exp" + flag name, for example, expsql. Try { // Your code Try { // Code } Catch (exception exp) { // Your code } } Catch (exception expsql) { // Your code } Supplement: if you do not need to handle exceptions, you do not need to define an exception instance. Example: Try { // Your code } Catch (exception exp) { }   Since most names are constructed by concatenating several words, use a mix of upper and lower cases to simplify their reading. The first letter of each word is in uppercase. 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. Use complementary pairs in variable names, such as min/max, begin/end, and open/close. Do not use the original numeric or string, such as for (I = 1; I <= 7; I ++ ). Instead, use the naming constants, such as for (I = 1; I <= num_days_in_week; I ++) for maintenance and understanding. B) control naming Control name = the first two to three letters and names of the Control name, for example, labl control (labusername) 5.2 constant name The constant name must also have a certain meaning, in the format of "noun" or "noun_verb. The constant names are in uppercase and separated by underscores. Example: Private const bool web_enablepagecache_default = true; Private const int web_pagecacheexpiresinseconds_default = 3600; Private const bool web_enablessl_default = false; Note: Variable names and constant names can contain a maximum of 255 characters. However, names with more than 25 to 30 characters are clumsy. In addition, to get a meaningful name and clearly express the purpose of a variable or constant, 25 or 30 characters should be enough. 5.3 class naming A) The name should be able to identify the characteristics of things. B) Try not to use abbreviations unless they are well known. C) A name may consist of two or three words, but generally should not contain more than three words. D) In the name, the first letter of all words is capitalized. For example, issuperuser, which contains IDs, all in uppercase, such as customerid. E) Use a noun or a noun phrase to name a class. F) Use less abbreviations. G) do not use the underscore (_). Example: public class filestream Public class button Public class string 5.4 interface naming The same as the class naming convention, the only difference is that the interface is prefixed with "I" before the name. Example: Interface idbcommand; Interface iButton; 5.5 Method naming Same as the class naming rules. 5.6 namespace Same as the class naming rules. 6 encoding rules 6.1 error check rules A) in programming, various execution conditions of functions should be considered, and all process conditions should be handled as much as possible. B) Check all system call errors unless errors are ignored. C) divide functions into two categories: one is irrelevant to the display of the screen, and the other is related to the display of the screen. For functions unrelated to screen display, the function reports errors through the return value. For functions related to screen display, the function is responsible for issuing warnings to users and handling errors. D) The error handling code is generally placed at the end of the function. E) for common error handling, you can create common error handling functions to handle common errors. 6.2 braces Place braces in the same column below the keyword, for example: If ($ condition) while ($ condition) {{ ...... }} 6.3 indent rules Use a tab to indent each layer. For example: Function func () { If (something bad) { If (another thing bad) { While (more input) { } } } } 6.4 parentheses A) do not enclose parentheses with keywords (such as if and while) and separate them with spaces. B) do not enclose parentheses with function names. C) 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. 6.5 if then else rules If you use the else if statement, it is usually better to have an else block to handle other unprocessed situations. If possible, place a record information comment in else, even if there is no action in else. The format is: If (condition 1) // comment { } Else if (condition 2) // comment { } Else // Annotation { } NOTE: If and loop nesting allows up to four layers 6.6 comparison rules Always place the constant value on the left of the equal sign/non-equal sign. One reason is that if you miss an equal sign in the equation, the syntax examiner will report an error for you. The second reason is that you can immediately find a value instead of finding it at the end of your expression. For example: If (6 = $ errornum )... 6.7 case rules The default case always exists. If it is not allowed to arrive, it should be ensured that an error will be triggered if it arrives. It is best to use Int or string type for case selection conditions. 6.8 alignment rules The declaration and initialization of variables should be aligned. For example: Int m_icount; Int I, J; Float m_fincome, m_fpay;   M_icount = 0; I = 1; M_fincome = 0.3; 6.9 single statement rules Unless these statements are closely related, only one statement is written in each line. 6.10 single function rules In principle, a program unit (function, routine, method) can only complete one function. 6.11 simple function rules In principle, the code of a program unit should be limited to one page (25 ~ 30 rows ). 6.12 clear conditions and rules Do not use the default value to test the non-zero value. For example, if (0! = F () "instead of" If (f ())". 6.13 select the false rule Most functions return values such as false, 0, or no in case of an error, but the returned value is not fixed when it is correct (cannot be represented by a fixed value of true, 1, or yes ), therefore, an inequality such as false, 0, and no should be used to detect a Boolean value. For example, if (false! = F () "instead of" If (true = f ())". 6.14 independent assignment rules Embedded assignment is not conducive to understanding the program, and may cause unexpected side effects. You should try to write independent assignment statements. For example, use "A = B + C; E = a + D;" instead of "E = (A = B + C) + d ". 6.15 define constant rules For constants referenced in the Code (especially numbers), define should be an upper-case name, referencing the name in the code without directly referencing the value. 6.16 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. 6.17 communication rules Share others' work results and provide others with their work results. In task development, if there are other encoding rules, they are clearly defined in the corresponding software development plan. 7 programming principles 7.1 variable usage A) global variables cannot be defined at will. B) a variable can only have one purpose. The purpose of the variable must be consistent with the name of the variable. C) all variables must be defined at the beginning of the class and function and sorted by class. 7.2 database operations A) when searching database tables or views, you can only retrieve the required fields. B) use a non-correlated subquery instead of an associated subquery. C) use the column name clearly, but not the sequence number of the column. D) Use transactions to ensure data integrity. 7.3 object usage A) create an object as late as possible and release it as early as possible. 7.4 Module Design Principles A) public functions and classes cannot be defined at will. B) a single function does not allow one function to implement two or more functions. C) You cannot use global variables within a function. To use global variables, convert them to local variables. D) Only the inclusion relationship exists between the function and the function, rather than the cross relationship. That is, there is only one-way call and called between the two, there is no two-way call and called. 7.5 structured requirements A) two equivalent branches are prohibited. Example: If (A = 2) Else if (a = 3) // Else if (a = 2) // Else // B) avoid using the GOTO statement. C) use the if statement to emphasize that only one of the two groups of statements is executed. Disable else Goto and else return. D) Use Case to implement multiple branches E) Avoid Multiple exits from the loop. F) The function has only one exit. G) The Conditional Value assignment statement is not used. H) Avoid unnecessary branches. I) do not replace logical expressions with conditional branches easily. 7.6 function return value principle 1) function return value Avoid using struct and other complex types Bool type: This function only needs to obtain the success or failure response information. Int type: the error code is negative. 0 is returned if the error code is successful. 8. code package specification In this project, each task should be packaged and archived after a stable version is completed. 8.1 version number of the code package In the project, the version number of the 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 usage is as follows: 1) when the initial version of the code package is v1.00; 2) When the 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 first revision is made to the first version of the code package, the version number is v1.01; 3) when the code package adds some functions on the original basis and the release number remains unchanged, add 1 to the first digit of the Change number. For example, add some functions on the basis of v1.12, the new version is v1.20; 4) when the code package changes globally due to significant changes or a large number of partial revisions, 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. 8.2 code package ID The Code packages generated in this project have unique and specific codes. The Code packages are constructed as follows: S-Project ID-code package type-version number/serial number Where: 1) S: ID of the project, indicating that the project is "XXXX ". 2) Project ID: A Brief identifier of the project. This identifier applies to documents of the entire project. 3) code package type: two letter codes from the following table. 4) version number: the version number of this code package. 5) serial number: four-digit code, indicating the total serial number of the code package in the project code base. For example: A Windows RAR source code compressed package named: S-XXXX-WS-V1.02/0001 Project code package classification table Code injection for class Encoding RAR package (Web) source code file ws source code package Compile the WB file package Install file wi installation package Source code + Installation File wa source code and installation package   The identification list of all code packages in the project will be defined in the project development plan. 9 code control 9.1 create a code library/directory The project owner builds the project target document library directory in VSS, that is, the "software" directory for quick query. 9.2 code Archiving After a stable version of all code is completed, the project owner should package the code and store it in the "software" directory of the target in VSS, A unique name is assigned to the code package according to the code package naming rules. 10 input control validation rules 10.1 login Control User Login ID and password. to limit the input length, you must check the validity of the input. 10.2 Data Entry Control A) textbox Input 1. Ensure that the length of user input and database reception is consistent. 2. Check the input validity. E. g.: e_mail format XXX@XXX.XXX... Telephone format: 020-12345678 (020) 12345678 The zip code is six digits. B) Except for checkbox and radiobutton, it is prohibited to embed other editing controls in the DataGrid to add and edit data. 11. Database naming rules: Sqlserver naming rules The use of this system follows the following naming rules: 1. Table naming: A table is composed of one or three or more English words. The first letter of the word is capitalized, for example, departmentusers; 2. The table primary key name is: Table name + id, for example, the document table primary key name: entid 3. Stored Procedure name: Table name + method, for example, p_my_newsadd, p_my_newsupdate; 4. View name: VIEW _ table name, for example, viewnews; 5. status is the name of the table's state column. The default value is 0. Deleting a table changes the status value and does not actually Delete the record; 6. checkintime is the time column for adding records. The default value is system time; 7. Do not use the database user name because all objects such as tables, stored procedures, and views are DBO. Changes to database users are affected. Appendix 1: abbreviated data type table   Abbreviated Data Type String Str Int I Char Chr Sbyte sb Byte BT Uint UI Long L Ulong ul Float F Double D Bool B Decimal Dec   Note: Database Server naming rules: Control name abbreviation + full name of control words, such as btnnext, txtpassword (Password text box), txtrpassword (Password Confirmation text box ), the first letter of a word must be capitalized. If there are multiple words, it is the abbreviation of the Control + the first word used by the Control + the full name of the second word. the first letter of each word name must be capitalized. Appendix 2: Server Control name abbreviations A. Web controls Web Control name Adrotator Art Button BTN Calendar CD Checkbox CHK Checkboxlist chkl Comparevalidator CPV Customvalidator CTV DataGrid DG Datalist DL Dropdownlist DDL Hyperlink HL Image img Imagebutton ibtn Label lab Linkbutton lbtn ListBox lst Panel pl Placeholder pH Radiobutton Rb Radiobuttonlist RBL Rangevalidator RV Regularexpressionvalidator Rev Repeater RP Requiredfieldvalidator rfv Table TB Tablecell TC Tablerow tr Textbox txt Validationsummary XML B. html controls Abbreviation of HTML Control Htmlanchor hah Htmlbutton hbtn Htmlform hform Htmlgenericcontrol HGC Htmlimage himg Htmlinputbutton (button) htxt Htmlinputbutton (reset) hrbtn Htmlinputbutton (submitted) hcbtn Htmlinputcheckbox hick Htmlinputfile hifile Htmlinputhidden hihidden Htmlinputimage hiimg Htmlinputradiobutton hirb Htmlinputtext (password) hpwd Htmlinputtext (text) hitxt Htmlselect hslt Htmltable htab Htmltablecell HTC Htmltablerow hTR Htmltextarea htxta C. Ado. Net Control naming rules Type prefix example Connection con connorthwind Command cmd cmdreturnproducts Parameter parm parmproductid Dataadapter dad dadproducts Datareader DTR dtrproducts Dataset DST dstnorthwind Datatable dtbl dtblproduct Datarow Drow drowrow98 Datacolumn dcol dcolproductid Datarelation drel drelmasterdetail Dataview dvw dvwfilteredproducts