. NET platform development practice some bit summary (Technical specification and Practice Essence) 1th 2 Page _ Practical Skill

Here is my right. NET platform development practice some bit summary. The technical specifications here are mainly code specifications of the development process, database design specifications, COM and. NET interoperability specifications, and the practice essence is a part of the process of technical practice.

First, code specifications

Good code style comes from the same code specification. Good-style code is not only readable and maintainable, but also gives people a smooth, pleasing pleasure.

According to Microsoft, in the development of the Microsoft platform, 70-80% Indian engineers used the same code when they finished the same algorithms or modules, while only 20% of the Chinese engineers in the same survey were basically consistent. This shows that our code production process needs to be standardized.

Literal naming

types, variables, constants, methods and other identifiers are all used in the corresponding English literal; if two separate, literal words are involved, the middle is underlined or the first letter of the word is capitalized (in two ways), and if the identifier is longer than 30 letters, the accent syllable, which is pronounced in English words, picks up three letters. , such as repeater used rpt,management with Mgt.

Case rules

There are generally two kinds of capitalization rules:

Pascal case form, all words first letter uppercase, other letter lowercase.

Camel case, except for the first word, all words are capitalized in the first letter and the other letters are lowercase.

Class name using Pascal case

public class HelloWorld (or Hello_world, with the same below, no longer repeat) { ... }

Method uses Pascal capitalization

public class HelloWorld () { void SayHello (string name) { ... } }

Variables and method parameters use camel case

public class HelloWorld () { int totalcount = 0; void SayHello (string name) { String fullmessage = "Hello" + name; ... } }

Do not use Hungarian methods to name variables

In the past, most programmers preferred to prefix a variable name with a data type and m_ as a member variable. For example: string M_sname;int nage;

However, this way in. NET coding specification is not recommended. All variables are prefixed with camel, rather than data types and m_.

Replace Nam,addr,sal with Name,address,salary and so on.

Don't use a single letter variable like i,n,x. Use Index,temp and so on. Variable exception for loop iteration:

If the variable is used only for the iteration count, not elsewhere in the loop, it is allowed to be named with a single letter variable, rather than a separate literal name.

The filename should match the class name, for example, for class HelloWorld, the corresponding file name should be HelloWorld.cs.

Indentation and Spacing

Indent tab with no spaces.

Comments need to be aligned with the code.

Follow the VS2005 automatic alignment rules, not artificially adjusted.

Separate the logical groupings of your code with a blank line.

In a class, the implementation body of each method must be separated by a blank line, and the large bracket "{}" needs a separate row.

Each operator and parenthesis are blank before and after. Such as:

If (Showresult = = True) { for (int i = 0; i < i++) { // } }

Instead of:

if (showresult==true) { for (int i= 0;i<10;i++) { // } }

Good programming habits

Avoid using large files. If the code in a file exceeds the 300~400 line, you must consider separating the code into different classes.

Avoid writing too long a way. A typical method code is between 1~30 lines. If a method sends more than 30 lines of code, you should consider splitting them into different methods.

The method name needs to be able to see what it does. Don't use names that can cause misunderstanding. If the name is clear, there is no need to use documentation to explain the function of the method.

One method completes only one task. Don't combine multiple tasks into one method, even if those tasks are very small.

Use the unique type of C #, not the alias type defined in the System namespace. Such as:

int age; String name; Object ContactInfo;

Instead of:

Int16 age; String name; Object ContactInfo;

This is done on the basis of the following two reasons: (1) normative and consistent; (2) facilitates porting across language platforms.

Do not use fixed values in the program, instead of constants. Do not use string constants, use resource files as much as possible.

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

Do not share member variables between methods, and it is difficult to know which method changed its value when it was shared among several methods. Use an enum when necessary, and do not use numbers or strings to indicate discrete values.

Do not declare member variables public or protected. are declared private and use public/protected properties.

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

The application starts with a "self-test" and ensures that the required files and attachments are in the specified location. Check the database connection if necessary, and give the user a friendly hint if any problems arise.

If the required configuration file is not found, the application needs to be able to create its own default values. If an error value is found in the configuration file, the application throws an error, giving a prompt message telling the user the correct value. The error message needs to be able to help the user solve the problem.

Comments

Do not each line of code, each declared variable is commented. Comment where needed.

Readable code requires very few annotations, and if all the variables and methods are named with meaning, it makes the code very readable and does not require too many annotations. A comment with a few lines makes the code look elegant.

If you use complex and abstruse principles for some reason, you must have good documentation and detailed annotations for your program.

Make spelling checks on annotations to ensure proper use of grammar and punctuation.

Ii. Code for Database design

Table Classification and naming

Classification of data tables

The system table supports the data table of the business model, such as process model, System management related table.

Business table products provided by the general function of the business module related tables, such as general business inquiries.

User table two times users develop and use the specific business-related data sheets.

Name of data table

All tables are named with the letter "T" (table), and the "_" interval is underlined by a literal word.

system table system table prefix is: tsys_

The Business table prefix is: tbiz_

The user table is defined by the user, but it is not recommended to repeat the naming rules for system tables and business tables.

Name of the field

The naming rules for fields refer to the naming rules for code identifiers, but note that the reserved words for the database are bypassed. For example, do not use this field name: Index,field,password,id,oracle,sql and so on.

For the system table involving the technical core, in order to prevent the analysis, it is suggested to adopt a similar "F1,f2,f3 ..." The way of Fn named. But do not use "F0", because the name is not allowed in some databases, such as InterBase.

The establishment of the index

Index is a double-edged sword, index will improve the efficiency of query, but reduce the efficiency of insert/delete/update.

Typically, the editing frequency and time limit of the data is much lower than the query requirements for the database, so you must index the data tables that record a lot and frequently query.

Most databases automatically create indexes for primary key fields, and note that indexes are created for foreign keys.

Do not index large fields so that the index takes up 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 primary key of the table, which will affect the data migration of the table. If you consider supporting multiple databases, it is recommended that the primary key take the unique value that is generated by the program.

If a large table needs frequent insert/delete/update operations and high concurrency queries, it is advisable to split the table based on the frequency of data access and then establish an index.

Current 1/2 page 12 Next read the full text