C # writing specification
First, name
The naming scheme is the most influential help for understanding the logic flow of the application. The name should be "What" instead of "how". The abstract layer of simplified complexity can be retained by avoiding the name of the publication of the publication of the publication (they will change). For example, getNextStudent () can be used instead of getNextArrayElement ().
Naming principle is:
Difficulties when choosing a correct name may indicate a further analysis or definition item. The name is long enough to have certain significance and short enough to avoid lengthy. The only name is only used on programming only to separate each zone. The name of the performance is to help people read; therefore, it is meaningful to provide people's understanding. However, make sure that the selected names meet the rules and criteria for the applicable language.
The following points are recommended naming methods.
1, method, attribute, variable specification
Avoiding an unknown name, such as analog name xxk8, or attribute name xxk8. Such names can cause polynsity.
In an object-oriented language, the name of the class attribute is redundant, such as Book.bookTitle. But you should use book.title.
Use the verbs-noun to name routines that perform specific operations for a given object, such as CalculateInvoiceTotal ().
All overloads should perform similar functions in the language that allows the function overloaded.
As long as it is appropriate, the limitator (AVG, SUM, MIN, MAX, INDEX) are calculated at the end of the variable name.
Using complementaries in the variable name, such as MIN / MAX, Begin / End, and Open / Close.
In view of the fact that most names are constructed by connecting several words, use case-write mixed formats to simplify their reading. In addition, in order to help distort variables and routines, use PASCAL INVOICETALs in the routine name, where the first letter of each word is capitalized. For variable names, use Camel case write processing (DocumentFormatType), where the first letter of each word except the first word is capitalized.
The Boolean variable name should contain IS, which means yes / no or true / false value, such as Fileisfound.
When naming status variables, the terms such as FLAG are avoided. The state variable is different from the Boolean variable is that it can have two possible values. Not using DocumentFlag, but use more descriptive names, such as DocumentFormattype. (This item is for reference only)
The meaningful name is still used even for variables that may only appear in a few code lines. Use a single-letter variable name only for short cyclic indexes, such as I or J.
Wherever possible, try not to use the primary number or primary string, such as for i = 1 to 7. But use naming constants, such as for i = 1 to num_days_in_week for maintenance and understanding.
Second, code writing specification
Formatting makes the logical structure of the code. It takes time to ensure that the source code is formatted in a consistent logic, which has great help to you and your development group and other developers who maintain source code in the future.
The following points are recommended formatting methods.
Establish standard indentation sizes (such as four spaces) and use this standard consistently. Aligns the code section with the specified indentation.
Use a specific font and a font size (New Song, small 5) when the hard copy version of the release source code is released.
In the brackets, the position of the alignment is vertically left parentheses and the right brackets, such as:
For (i = 0; i <100; i )
{
;
}
It is also possible to use the tilt pattern, that is, the left parentheses appears in the row, the right brackets appear in the lead, such as for (i = 0; i <100; i ) {
;
}
Regardless of which style is selected, use that style throughout the source code.
Corriding the code along the logical structure. There is no indentation, the code will become difficult to understand, such as:
IF (Expression)
{
//
// Fill in your code block here;
//
}
IF (Expression)
{
//
// Fill in your code block here;
//
}
Else
{
//
// Fill in your code block here;
//
}
The indented code produces a code that is easier to read, such as:
IF (Expression)
{
IF (Expression)
{
//
// Fill in your code block here;
//
}
Else
{
//
// Fill in your code block here;
//
}
}
Establish the maximum performance for comments and code to avoid the scroll source code editor, and can provide neat hard copy representations.
Use spaces before and after most operators, do not change the intent of the code. However, the pointer representation used in C is an exception.
Provide structure clues for source code using blank. This will create code "segments" to help readers understand the logical segmentation of the software.
When a line of content is too long, the indentation format is used in the back wrap code, as follows:
String inserstring = "Insert Into Tablename (Username, Password, Email, SEX, Address"
"Values ('Soholife', 'Chenyp', 'Soholife@sina.com', 'Male', 'Shenzhen Futian')
As long as it is suitable, the statement placed on each line avoids more than one. Exceptions are cycles in C, C , C # or JScript, such as FOR (i = 0; i <100; i ).
When writing HTML, establish a standard tag and attribute format, such as all tags, uppercase or all properties are lowercase. Another way is to adhere to the XHTML specification to ensure that all HTML documents are valid. Although the file size is considered when you create a web page, you should use the attribute values of quotation marks and end tags to facilitate maintenance.
When writing SQL statements, use all uppercases for keywords, use case-write mixing for database elements (such as tables, columns, and views).
Source code logically between physical files.
Place each primary SQL clause on a different line, which is easier to read and edit statements, for example:
Select Firstname, Lastname
From customer
Where stat = 'wa'
The large complex code segment is divided into smaller and easy to understand.
Third, notes
Software documents exist in two forms: external and internal. External documents (such as specification, help files, and design documents) are maintained at the source code. The internal document consists of a comment composed of developers in the source code during development.
Do not consider the availability of external documents, due to hard copy files, the source code list should be able to exist independently. The external document should be composed of specification, design documents, change requests, error history, and coding standards used.
One problem with internal software documents is to ensure that the maintenance and update of the comment are simultaneously in the same time. Although the correct note source code does not have any use at runtime, it is invalvible for developers who must maintain a particularly complex or troubleshooting software.
The following points are recommended notes: If developed with C #, use the XML document format, such as comments below:
///
// get someone's age
///
/// Username
///
Public int getUserage (String Username)
{
//
/ / Write your program code here
//
}
When modifying the code, you always keep the comments around the code up to date.
At the beginning of each routine, provide standard annotation samples to indicate the use, assumptions, and limitations of the routine. Note The sample should be to explain why it exists and what can be done.
Avoid adding a comment at the end of the code line; the line end is more difficult to read. However, in the annotation variable declaration, the end of the notes is appropriate; in this case, all the end of the end is aligned at the common surface place.
Avoid messy comments, such as a whole line number. Instead, you should use a blank to separate the comment.
Avoid adding a print box around the block annotation. This seems to be very beautiful, but it is difficult to maintain.
Remove all temporary or unrelated comments before deployment to avoid confusion in future maintenance work.
If you need to use a comment to explain the complex code section, check this code to determine if it should be overridden. Do everything possible not to note the code that is difficult to understand, but should override it. Although it is generally not to make the code to sacrifice performance, it is necessary to maintain a balance between performance and maintainability.
Use a complete sentence when writing a comment. Note The code should be clarified without increasing polymity.
Note when writing the code, because there is no time to do so later. In addition, if you have the opportunity to review the prepredible code, it seems that it seems that it seems that it is not obvious after six weeks.
Avoid excess or inappropriate annotations, such as humorous nonsense.
Use comments to explain the intent of the code. They should not be used as an online translation.
Not very obvious in the comment code.
In order to prevent problems from repeatedly, the error repair and solution code is always used, especially in the team environment.
Use the code consisting of cyclic and logical branches. These are the main aspects of helping the source code readers.
In the entire application, construct the annotation using a uniform style with a consistent punctuation and structure.
Use a blank to separate the comment separator separator. This will make the comment significantly without color prompts, which makes the comment obvious and easy to find.
