Summary of. Net platform development practices (Technical Specifications and practices) page 1/2

The following is my summary of the development practices of the. Net platform. The technical specifications here mainly refer to the code specification, database design specification, Com and. Net interoperability specification in the development process. The essence of practice is a summary of the technical practices.

I. Code specifications

A good code style comes from the same code specification. Code with good style not only has readability and maintainability, but also provides a pleasant experience.

According to Microsoft statistics, 70-80% of Indian Engineers used the same type of algorithms or modules during development based on the Microsoft platform; in the same survey, only 20% of Chinese engineers are basically the same. This shows that our code production process needs to be standardized.

Real name

All types, variables, constants, methods, and other identifiers use corresponding English meanings. If two independent words are involved, the spacing is separated by an underscore or the first letter of a word (both methods are acceptable). If the length of an identifier exceeds 30 letters, in this case, three letters are selected from the re-stressed syllable of an English word, such as rpt for Repeater and mgt for Management.

Case sensitivity rules

Currently, there are generally two case-insensitive rules:

Pascal is case-sensitive. The first letter and other letters of all words are in upper case.

Camel is case-sensitive. Except the first word, the first letter and other letters of all words are in upper case.

Class Name in Pascal case

Public class HelloWorld (or Hello_World, which is the same as below and will not be repeated) { ... }

Method Pascal case

Public class HelloWorld () { Void SayHello (string name) { ... } }

Variables and method parameters are in the Camel case-sensitive format.

Public class HelloWorld () { Int totalCount = 0; Void SayHello (string name) { String fullMessage = "Hello" + name; ... } }

Do not use the Hungary method to name variables

In the past, most programmers liked to use the data type as the prefix of the variable name and m _ as the prefix of the member variable. Example: string m_sName; int nAge;

However, this method is not recommended in. NET encoding specifications. All variables are in the Camel case format, instead of using the Data Type and m _ as the prefix.

Replace nam, addr, and sal with name, address, and salary.

Do not use single-letter variables such as I, n, and x. Use index, temp, etc. Variable exceptions used for loop iteration:

If the variable is only used for iterative counting and does not appear elsewhere in the loop, you can use a single letter of variable name instead of an actual name.

The file name must match the class name. For example, for the class HelloWorld, the corresponding file name should be helloworld. cs.

Indentation and interval

TAB is used for indentation, and SPACES is not used.

The annotation must be aligned with the code.

Follow the automatic alignment rules of VS2005 and do not adjust them manually.

Use a blank line to separate the logical grouping of code.

In a class, the implementation bodies of each method must be separated by empty rows, and the large arc "{}" must be an independent row.

Each operator and bracket have a blank space. For example:

If (showResult = true) { For (int I = 0; I <10; I ++) { // } }

Instead:

If (showResult = true) { For (int I = 0; I <10; I ++) { // } }

Good Programming habits

Avoid using large files. If the code in a file exceeds 300 ~ Line 3: Separate the code into different classes.

Avoid writing too long. A typical method code is in the range of 1 ~ Between 30 rows. If a method sends more than 30 lines of code, you should consider breaking it into different methods.

The method name must be able to see what it does. Do not use a name that may cause misunderstanding. If the name is clear, you do not need to use documents to explain the functions of the method.

One method only completes one task. Do not combine multiple tasks into one method, even if those tasks are very small.

Use the special type of C # instead of the alias type defined in the System namespace. For example:

Int age; String name; Object contactInfo;

Instead:

Int16 age; String name; Object contactInfo;

This is based on the following two reasons: (1) standardization and consistency; (2) Ease of cross-Language Platform transplantation.

Do not use a fixed value in the program, instead of a constant. Do not use string constants. Use source files whenever possible.

Avoid using many member variables, declare local variables, and pass them to methods.

Do not share member variables between methods. If a member variable is shared among several methods, it is difficult to know which method modifies its value. Use enum if necessary. Do not use numbers or strings to indicate discrete values.

Do not declare the member variables as public or protected. Are declared as private and use the Properties of public/protected.

Do not use the specific path and drive name in the code, use the relative path, and make the path programmable. Never imagine that your code is running on the "C:" disk. You don't know, some users run programs on the network or "Z:" disk.

When the application starts, perform "self-check" and ensure that the required files and attachments are in the specified location. If necessary, check the database connection and give the user a friendly prompt if any problem occurs.

If the required configuration file cannot be found, the application must be able to create and use the default value. If an error value is found in the configuration file, the application will throw an error and a message will be prompted to tell the user the correct value. The error message must help you solve the problem.

Note

Every declared variable is annotated. Comment in the desired place.

Code with high readability requires few comments. If all the variables and methods have meaningful names, the code will be highly readable without too many comments. Comments with few lines will make the Code look elegant.

If complex and difficult principles are used for some reason, the program must be well documented and annotated in detail.

Check the spelling of comments to ensure correct use of syntaxes and punctuation marks.

Ii. Database Design Specifications

Table Category and naming

Data Table Category

System tables support data tables of business models, such as process models and system management tables.

The business table product provides tables related to common business function modules, such as common business queries.

User table data tables related to specific businesses used by users for secondary development.

Data Table Name

All tables are named at the beginning of the letter "T" (Table), and are separated by an underscore (_) following an actual word.

System Table System table prefix: TSYS _

Business table prefix: TBIZ _

User tables are defined by users. However, we recommend that you do not duplicate the naming rules of system tables and business tables.

Field name

The naming rules of fields refer to the naming rules of code identifiers, but note that the reserved words of the database are avoided. For example, do not use the following field names: index, field, password, id, Oracle, SQL, and so on.

For system tables that involve technical core, we recommend that you use a table similar to "F1, F2, F3..." to prevent analysis ...... Fn. But do not use "F0" because this name is not allowed in some databases, such as Interbase.

Index creation

Indexing is a double-edged sword. indexing improves the query efficiency, but reduces the efficiency of insert, delete, and update.

Generally, the frequency and time limit of data editing are much lower than the database query requirements. Therefore, you must create an index for data tables with many records and frequently queried records.

Most databases automatically create indexes for primary key fields. Note that indexes are created for Foreign keys.

Do not index large fields. This will make the index occupy too much storage space.

Try not to index small tables that are frequently edited.

The identify field should not be associated with other tables as the table's primary key, which will affect the data migration of the table. If you want to support multiple databases, we recommend that you use the unique value generated by the Program for the primary key.

If a large table requires frequent insert/delete/update operations and high-concurrency queries, we recommend that you split the Table Based on the Data Access frequency and create an index.