Visual Studio
Please refer to the encoding method
Coding Method and Programming | Program Structure and Code Admission | XML Document | Visual Basic Naming Convention
The encoding method combines many aspects of software development. Although they usually have no effect on the functionality of the application, they are helpful for improving the understanding of source code. All forms of source code are considered, including programming, scripting, tag, and query language.
It is not recommended to form a fixed coding standard in the encoding method defined here. Instead, they aimed at the guidelines for developing coding standards for specific software projects.
The encoding method is divided into three parts:
name
Comment
format
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 that the purpose of further analysis or definition is required. 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.
Routine
Avoiding an unknown name that is subjectively explained, such as analyzethis () for routines, or XXK8 for variables. Such names will cause polynsity, not just abstraction.
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. For those languages that are not allowed to be overloaded, establish a naming standard with similar functions.
variable
As long as it is suitable, the calculation qualifier (AVG, SUM, MIN, MAX, INDEX) are added 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.
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.
Do not use primary numbers or primary strings, 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.
table
When name a table, use a single form. For example, using Employee instead of EMPLOYEES. When the column of the named table, do not repeat the name of the table; for example, avoid using the field named EmployeelastName in a table named Employee.
Do not include data types in the name of the column. This will reduce workload if necessary to change the data type.
Microsoft SQL Server
Do not add a SP prefix to the stored procedure, which is preserved for identifying the system stored procedure.
Do not add a FN_ prefix to the user-defined function, which is preserved to identify the built-in function.
Do not add an XP_ prefix to the extended stored procedure, this prefix is reserved for the identification system extension stored procedure.
Miscellaneous
Try to reduce the use of abbreviations, but use abbreviations created in conjogenization. The abbreviation should only be one; the same, each abbreviation should also have only one abbreviation. For example, if you use MIN as the abbreviation of Minimum, you should do this in all places; don't use MIN as an abbreviation of Minute.
Include the return value for the naming function, such as getCurrentWindowname ().
Like the process name, the names of the files and folders should also exact their use.
Avoid reuse the names of different elements, such as routines called ProcessSales and variables named iProcessSales.
Avoid homonyms (such as WRITE and RIGHT) when naming elements to prevent confusion when checking the code.
When naming elements, avoid using universal miscible words. In addition, there should be differences between regional spellings, such as Color / Color and Check / Cheque.
Avoid using print tags to identify data types, such as using $ representative strings or use% represent an integer.
Comment
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 function. For more information, see: XML documentation.
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.
format
Formatting makes the logical structure of the code. It takes time to ensure that the source code is formatted in a consistent logic, which is helpful for you and other developers who must decrypt source code.
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 the monotype font when the hard copy version of the release source code.
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 appear 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 ... then
IF ... then
...
Else
END IF
Else
...
END IF
The indented code produces a code that is easier to read, such as:
IF ... then
IF ... then
...
Else
...
END IF
Else
...
END IF
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 is divided into a few lines, by placing the series operator in the end of each row, it is clear that there is not a complete line.
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 ).
