C #. NET encoding specification, c #. net Encoding

C #. NET encoding specification, c #. net Encoding

 

I,Environment Settings

First, remove the following options in the development environment:

 

Figure 1

 

Figure 2

II,Naming rules

1) versatility

L The total length of the logo cannot exceed 32 characters.

L The basic syntax of an identifier is a word consisting of letters, numbers, and underscores (_). The first character cannot be a number.

L if appropriate, append the calculation qualifier (Avg, Sum, Min, Max, Index) at the end of the variable name ).

L use complementary pairs in variable names, such as min/max, begin/end, and open/close.

L Boolean variable names should be prefixed with or contain Is (is ).

L try to minimize the use of abbreviations, but use the abbreviations created in a consistent manner. The abbreviation should have only one meaning. Similarly, each abbreviation should have only one abbreviation. For example, if min is used as the abbreviation of minimum, it should be done in all places; do not use min as the abbreviation of minute again.

L include a description of the return value when naming a function, such as GetCurrentWindowName ().

L avoid reusing names for different elements, such as routines named ProcessSales () and variables named iProcessSales.

L avoid out-of-the-box homophone meanings (such as write and right) when naming elements to avoid confusion during code check.

L avoid commonly misspelled words when naming elements. In addition, you should be clear about the differences between spelling areas, such as color/color and check/cheque.

L avoid using the same name as the name in the external range within the internal range. If an error variable is accessed, an error is returned. If a variable conflicts with a keyword of the same name, you must add an appropriate type library before the keyword for identification. For example, if there is a variable named date, you can only use the internal Date function by calling System. Date.

L The interface name starts with "I", followed by a noun or noun phrase (such as IComponent), or an adjective (such as IPersistable) that describes the interface behavior ). Do not use underscores. Do not use abbreviations too much because abbreviations can cause confusion.

L The Name Of The event handler starts with a term describing the event type, followed by the suffix "EventHandler", such as "MouseEventHandler ". The name of the event parameter class must be suffixed with "EventArgs.

L if an event contains the concept of "before" or "after", use the prefix in the current or past format, such as "ControlAdd" or "ControlAdded ".

L split a single long string into multiple lines for writing. When a row is divided into several rows, the concatenation operator must be placed at the end of each row.

L in SQL Server, do not add sp prefix to stored procedures/do not add fn _ prefix to user-defined functions/do not add xp _ prefix to extended stored procedures. These prefixes are reserved for the identification system. Place each major SQL clause on different rows, making it easier to read and edit statements.

L do not use a literal number or a literal string, such as For I = 1 To 7. Instead, we use a naming constant, For example, For I = 1 To NUM_DAYS_IN_WEEK, To facilitate maintenance and understanding.

2) variable naming

Naming rules for variable names: Adjectives + nouns (or nouns)

L The class attributes correspond to the same private variables as the class attributes.

The private variable corresponding to the class property is added "_" before the class property name.

For example, private int _ PageSize; // private variable corresponding to the class attribute

Public int PageSize {set {_ PageSize = value ;}// class attribute

L ensure that the case sensitivity is consistent. The first letter of each word must be in uppercase. The first letter of other words is also capitalized. No "_" is added between words.

L do not use public to define an attribute.

L The attribute name and class name start with a noun, such as EmployeeName and CarAccessory.

L short syntax (private variable in the method/variable that is not frequently used)

Add "_" before u Definition

U, for example, string _ strSQL = null;

U The first letter of the first word must be in lower case, and the first letter of other words must be in upper case. No "_" is added between words.

L long-term (class private variables/method entry parameters)

U class private variable: Add "_" before, and the private variable corresponding to the class property is the same. The first letter of each word must be in uppercase. The first letter of other words is also capitalized. No "_" is added between words.

For example, private int _ PageSizeTmp;

U method entry parameter: the first letter of the first word must be in lower case, and the first letter of other words must be in upper case. If only one word is in lowercase. No "_" is added between words.

For example, public static int SendCTTVOSMS (string mobile, string content)

Public static string CallAccountHiVA (string restPhone, string userPhone)

L The definition must be in uppercase. For example, public static int SMS_TYPE = 2;

L The definition can also be in lower case.

For example, public static string VOSMS_UserName = "88000002 ";

L separate words.

3) function naming

Function naming rules: Verb + noun (or verb). The first letter of each word must be capitalized. No "_" is added between words.

For example, public static string GetOrderStatus (int sendMode, int statueID)

The function name and method name start with a verb, such as InitNameArray () and CloseDialog ().

4) control naming

Control naming rules: Category + name

Category Table:

Prefix	Type
Frm	Window
Btn	Button
Cbo	Drop-down list box
Txt	Text input box
Lbl	Tag
Img	Image
Pic	Image
Div	DIV
Grd	Grid
Scr	Scroll bar
Lst	List box
Sds	SqlDataSource
Ods	OleDbDataSource

For example, button: btnSave

 

Prefix	Type
B/is	Bool
C	Char
Sb	Sbyte
B	Byte
N/I	Int
Ui	Uint
L	Long
Ul	Ulong
F	Float
D	Double
S/str	String

 

5) Table field naming

L when naming a table, the name is expressed in the singular form. For example, use Employee instead of Employees.

L do not repeat the table name when naming the table columns. For example, avoid using the field "EmployeeLastName" in a table named "Employee.

L do not include data types in column names. If it is necessary to change the data type later, this will reduce the workload.

6) Name the Web file directory structure

L like the process name, the names of files and folders should also accurately describe their usage.

L the first character of the first word in a Web file must be in lowercase and the first character of other words must be in uppercase. Or all lowercase letters. After the file exists, the file must be imported into the program strictly according to the file's case sensitivity. The directory name must be in lowercase.

L Web directory structure:

Root --- Class Library 1

Class Library... N

Solution Startup File

Project release directory

Web source code --- inc (JS directory)

Css (CSS directory)

Background directory

Bin directory

App_data database directory

Master Directory

Other sub-function Directories

App_code File

Images image directory

 

III,Annotation Specification

1) mark the author of the file in the file header, the completion time, and its main functions.

2) After the program has been changed, you should write down the modifier, time, and simple reason list.

For example:

/*************************************** *****************************

* Who created the date and what function description

* Who modified the date and what function description

* Who added the date and what function description?

* Who repairs the function description of the deletion date?

**************************************** ****************************/

 

3) Comments in functions and other codes are automatically formatted according to the system comments.

For example:

 

 

4) When you modify the code, always keep the comments around the code up-to-date.

5) at the beginning of each routine, it is helpful to provide standard annotation samples to indicate the purpose, assumptions, and limitations of the routine. The annotation sample should be a brief introduction to why it exists and what it can do.

6) avoid adding comments at the end of the code line. comments at the end of the line make the code more difficult to read. However, it is appropriate to comment at the end of a row when the variable declaration is annotated. In this case, the comment at the end of all rows is aligned at the common tab.

7) Avoid messy comments, such as a whole planet number.

8) Remove all temporary or irrelevant comments before deployment to avoid confusion during future maintenance work.

9) If you need to use annotations to explain complex code sections, check the code to determine whether it should be overwritten. Rewrite the code without comments that are hard to understand. Although it is generally not necessary to sacrifice performance to make the code easier for people to use, it is necessary to maintain a balance between performance and maintainability.

10) use the complete sentence when writing comments. Comments should clarify the code without adding meaning.

11) comments when writing code, because it is likely that there is no time to do so in the future. In addition, if you have the opportunity to review the code you have written, it seems obvious that six weeks later may not be obvious.

12) Avoid unnecessary or inappropriate comments, such as humorous and non-main comments.

13) Use annotations to explain the intent of the Code. They should not be used as online translation of code.

14) Comment out nothing obvious in the code.

15) in order to prevent repeated problems, comments are always used for the error fixing and solution Code, especially in the team environment.

16) Use comments for codes composed of loops and logical branches. These are the main aspects to help source code readers.

17) construct comments using a unified style with consistent punctuation and structure throughout the application.

18) Use blank spaces to separate comments from comments. When you view comments without a color prompt, this will make the comments obvious and easy to find.

19) to prevent the source code editor from scrolling around when reading the Code, each line of code or comment must not exceed one display screen.

20) there may be many comments indicating the meaning of variables.

IV,Other code styles/habits

1) JS and CSS files must be UTF-8-encoded files.

2) The Single Row judgment Code does not need to be added with "{}".

For example, if (_ url. Trim (). Equals (String. Empty) return-2;

The code that can be abbreviated must be abbreviated. Make sure that every sentence of the code you write is a valid code.

3) do not use VS's automatic typographical code function.

4) Use less "=" operations. Use ". Equals" for comparison.

5) The operator must be left blank. For example, _ TotalPage = _ TotalRecord/_ PageSize does not change the code intent, but makes the code easier to read.

6) add an empty row after each operation. There cannot be two or more consecutive blank lines in all codes.

7) divide large complex code sections into small and easy-to-understand modules.

8) It is possible to use the TAB key to reserve space. Do not use four spaces to replace the TAB key.

9) The static type cannot be defined in the page file to transfer data.

10)