C # naming rules

ArticleDirectory

• 1.10 database naming

1. Naming Conventions

Pascal and camel naming conventions

There are two naming methods for programming: Pascal and camel (Pascal: the first letter of each word is capitalized, for example, producttype; CAMEL: the first letter of the first word is lowercase, and the first letter of other words is capitalized, for example, producttype)

The following are some common C # members and their recommended naming methods:

Identifier	Rules	Instance and description
Class	Pascal	Application
Enum	Pascal	Remember, it is named Pascal. do not include enum. Otherwise, fxcop will throw an issue.
Delegate delegate	Pascal	It is named after Pascal and does not distinguish it from the class name or function name with any special string.
Constant const	All uppercase	All uppercase letters, separated by hyphens
Interface	Pascal	Idisposable Note: it always starts with the I prefix and is named after Pascal.
Method Function	Pascal	Tostring
Namespace	Pascal	Separated by.. when each qualified word is named by Pascal, for example: Using excelquicker. Framework
Parameters	Camel	Lowercase letters
Local variable	Camel	You can also add a type identifier. For example, for the system. string type, the declared variable starts with STR, string strsql = string. empty;
Data Member	Camel	+ Pascal naming rules starting with M, such as mproducttype (M means Member)
Attribute	Pascal

 

1.1. Local variable naming

Use the camel naming rules when naming primitive local variables,

For example, int type = 0;

Double COUNT = 0;

...

For the definition of the string type, the STR prefix and Pascal naming method are usually used,

For example, string strsql = ""; // This is a typical method of naming SQL statement strings.

For the definition of another type object, the common practice is to use the OBJ prefix + Pascal name to inform us that this variable is an object. Alternatively, you can directly use the camel naming rules of the class name.

For example, application objapplication = new application ();
Application application = new application ();

 

1.2 parameter naming

Camel naming rules, lowercase letters

 

1.3 class data member/attribute naming

The data member name is camel, and the attribute name is Pascal. Generally, if the data member and attribute are paired, the data member and attribute name differ only from the first letter of the variable name in lower case or upper case.

For example

Class appcalition

{

Private arraylist worksheetcollection = new arraylist ();

Public arraylist worksheetcollection

{

Get

{

Return this. worksheetcollection;

}

}

}

In addition, when calling the Member Data/method of the class, the this qualifier should be added. This is Blue in the editing environment, which makes it easier for us to distinguish between local variables, parameters, or static variables, it is also conducive to fxcop detection and differentiation. (If fxcop is used for scanning and detectionCode)

 

1.4. namespace

Each character string between dots conforms to the Pascal format.

 

1.5. Delegation abbreviation

The name of the delegate is often named in Pascal, And the eventhandler is added after the name.

For example, public delegate void mouseeventhandler (Object sender, mouseeventargs E); // used to process mouse-related events or delegates

For a custom delegate, we recommend that you still use the object sender for the first parameter. Sender indicates the source object that triggers this time or the delegate. The second parameter inherits from the eventargs class and implements its own business logic in the derived class.

 

1.6. custom exception classes

The custom exception class ends with an exception and can clearly describe the cause of the exception in the class name. For example, notfoundfileexception describes that an object (file, memory area, etc.) cannot be found.

1.7 Enumeration

The name of the enumeration is Pascal. You do not need to add Enum to the enumeration. The enumeration name clearly indicates the purpose of the enumeration.

 

1.8. Constant naming

All uppercase words are separated by the following dashes, for example, public const int lock_seconds = 3000. Although Pascal is recommended for constant naming in msdn, from the naming rules of C ++, the difference between a constant and a common variable is more explicit when all constants are capitalized.

 

1.9 name abbreviations

In general, it is not recommended to name short variables. Do not worry about the variable name length. Long variable names can make the meaning of variables clearer. In fact, from the negative effect of long variable names, because Ctrl + C and CTRL + V are added with intelligent awareness in Vs, the negative tracing is very small. The principle of variable naming is to do your best to let others see our variables/functions /... You can probably guess what it is.

For example: int producttypecount = 0; // we can immediately know that it is a variable that records the number of products.

For a bad naming method: int prodtypecount = 0; // It is short for producttypecount. Some of us may know that prod is the abbreviation of product, but everyone can ensure that everyone knows about it. I personally think: The best code itself is annotation. As a first-classProgramMember. It not only implements functions, but also makes our code more elegant and capable of maintaining or expanding it in the future. As the current business system, the entry level of the threshold has been greatly reduced, and there is no difficulty in implementing functional requirements. However, the difference between the master and cainiao is that the master code is easy to understand, in the entire coding process, not only performance, but also code readability and maintainability can be considered.

1.10 database naming

We recommend that you use Pascal for naming database fields and table names. Of course, the use of long field names and table names may negatively affect the preparation of SQL statements. I recommend you use some Orm. The performance of ORM is certainly not better than writing SQL directly. However, if you do business systems, it is more important that the system can be delivered to users for a long time, orm not only shortens the development time, but also facilitates later maintenance than writing SQL directly.

2. annotation specifications

2.1 File Header comments

Comment in the header of the code file. The advantage of this is that we can track changes to the Code file. The Code header marks the founder, founding time, modifier, modification time, and code functions, which are essential for team development, they allow later maintenance/modification companions to know who they should ask for help in case of problems, it also knows how many iterations this file has experienced and how many programmers have developed and modified it.

Sample:

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

** Author: eunge

** Founding Date: 2004-6-8

** Modifier: Lucy

** Modification time: 2004-12-9

** Modifier: Lucy

** Modification time: 2005-01-29

** Description:

** Mainly used for product information input ,...

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

 

2.2 comments on functions, attributes, and classes

Use the // tri-diagonal line annotation. This annotation is based on XML and can not only export XML to create help documents, but also use various functions, attributes, and classes, the editing environment will automatically bring out comments for your development convenience. We recommend that you use this method to name comments with definitions declared by protected, protected internal, and public.

For example:

/// <Summary>

/// The class used to obtain product information from the ERP system

/// </Summary>

Class producttypecollector

{

...

}

 

2.3 logical point comments

Add comments where we think the logic is strong to describe the logic of this program, so that we can understand it later and understand it by others, in addition, the bug can be eliminated to a certain extent. Write our logic in the annotations, compare the program, and determine whether the program meets our original intention. If not, we should carefully consider whether the modified program is a comment or a program...

 

3. Layout

My typographical principles and suggestions:

1. Each statement occupies at least one line. If the statement is too long (more than one screen), the statement is broken into two lines;

2. Put similar content together, such as data members, attributes, methods, and events, and use # region... # Endregion: I like to put all the code generated by the machine in one # region, for example, compiling ASP. net Program, corresponding to the automatically generated control definition, I often use # region automatic generated Web components... # Endregion box them

3. Use space,

(1) Add spaces (+, =, &, etc.) before and after the binary operator, and index = index + 1;

(2) Add a space (!, ++ ,~ ), Index ++;

(3) commas and semicolons are only followed by Spaces

4. Use a blank line to insert a blank line between a function code or a function or attribute, Which is intuitive.

In Visual Studio 2005, the Code Formatting Function is provided. The shortcut key is Ctrl + k-> Ctrl + D.
 

4. Interface Control naming

I recommend that you use the default Control name as the prefix, And the prefix names are all in lower case. The advantage is that you do not have to worry about the Uniform Naming of unknown controls, such as for label Label controls, some people use LBL, some use lab, and some use lb. In this way, we still avoid using abbreviations. Sometimes the naming will become lengthy, but the naming can reflect the meaning of variables more effectively, and developers can perform better, because they do not need to memorize the abbreviations of each variable.

Protected system. Web. UI. webcontrols. Button buttonquery;

Protected system. Web. UI. webcontrols. dropdownlist dropdownlistproducttype;

Protected system. Web. UI. webcontrols. textbox textboxmanufacturedate;

 

5. Suggestions on code readability

(1) Pay attention to the operator priority. We should try to use parentheses to clarify the operation order of the expression to avoid the use of default priority, which may cause us and maintenance personnel problems.

(2) Avoid using numbers that are hard to understand and use meaningful identifiers instead (enumeration and constants)

For example:

If (producttype = 0) ... Else if (producttype = 1) ... (Not recommended)

If (producttype = producttype. CD) ... Else if (producttype = producttype. DVD) ... (Recommended)

 

(3) Try to use try statements for exception handling on the interface layer. Do not expose system-level errors to users directly, more importantly, the error information thrown by the system should be recorded in the log file to tell user-friendly prompt information.

In Visual Studio 2005, code layout formatting is quite useful. In fact, the code specification is to make the system have the same encoding style as a whole, so that later maintenance personnel can read and maintain the code more quickly. I think code standards have their own needs, but they cannot be standardized because of them. In terms of development, development aims to make a stable system faster, and stable systems are designed to benefit the company. Developers and project management personnel should come from the perspective of project management and consider problems from the perspective of companies and customers, rather than code.