Visual Studio coding specifications

Visual Studio Coding Method

The coding method combines many aspects of software development. Although they generally have no impact on the functionality of the application, they are helpful in improving the understanding of the source code. All forms of source code are taken into account, including programming, script writing, markup, and query languages.

We do not recommend that you set a fixed encoding standard for the encoding method defined here. Instead, they are intended to serve as guidelines for coding standards for developing specific software projects.

The encoding method consists of three parts:

• Name
• Note
• Format

Name

The naming scheme is the most influential help for understanding the logical flow of an application. The name should indicate "what" rather than "how ". By avoiding the name of the public basic implementation (which may change), you can retain the abstract layer that simplifies the complexity. For example, you can useGetNextStudent()InsteadGetNextArrayElement().

Naming rules are as follows: Selecting the correct name may indicate the purpose of further analysis or definition. Make the name long enough to make sense, and be short enough to avoid being too long. The unique name is only used to differentiate items. Strong performance names are used to help people read; therefore, names that people can understand are meaningful. However, make sure that the selected name complies with the rules and standards of the applicable language.

The following are recommended naming methods.

Routine

• Avoid obscure names that are easily subjective, suchAnalyzeThis()OrxxK8. Such a name will lead to ambiguity, not just abstraction.
• In an object-oriented language, it is unnecessary to include a class name in the class attribute name, for exampleBook.BookTitle. Instead, useBook.Title.
• Use the verb-Noun method to name the routine for performing specific operations on a given object, as shown inCalculateInvoiceTotal().
• In languages that allow function overloading, all overloading should execute similar functions. For languages that do not allow function overloading, establish naming standards for the relationship between similar functions.

Variable

• If appropriate, append the computing qualifier (Avg,Sum,Min,Max,Index).
• Use complementary pairs in variable names, such as min/max, begin/end, and open/close.
• Since most names are constructed by concatenating several words, use a mix of upper and lower cases to simplify their reading. In addition, to help distinguish between variables and routines, use Pascal case for the routine name (CalculateInvoiceTotal). The first letter of each word is in uppercase. For variable names, use camel case-sensitive processing (documentFormatType), The first letter of each word except the first word is in uppercase.
• The Boolean variable name should containIs, Which means yes/no or true/false, suchfileIsFound.
• When naming status variables, avoid usingFlag. A state variable has more than two possible values than a Boolean variable. Not useddocumentFlagInstead, use a more descriptive name, suchdocumentFormatType.
• Even for variables that may only have a short lifetime in several lines of code, they still use meaningful names. Only use single-letter variable names for short-cycle indexes, suchiOrj.
• Do not use the original numeric or string, as shown in figureFor i = 1 To 7. Instead, use the naming constant, as shown in figureFor i = 1 To NUM_DAYS_IN_WEEKTo facilitate maintenance and understanding.

Table

• When naming a table, the name is expressed in the singular form. For exampleEmployeeInsteadEmployees.
• When naming a table column, do not repeat the table name. For exampleEmployeeAvoid usingEmployeeLastName.
• Do not include data types in column names. If it is necessary to change the data type later, this will reduce the workload.

Microsoft SQL Server

• Do not addspPrefix, which is reserved for the system stored procedure.
• Do not add user-defined functionsfn_ Prefix, which is reserved for the built-in function.
• Do not add Extended Stored Proceduresxp_ Prefix, which is reserved to identify the Extended Stored Procedure of the system.

Miscellaneous

• 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.
• Include descriptions of return values when naming a function, as shown in figureGetCurrentWindowName().
• Like process names, the names of files and folders should also precisely describe their purposes.
• Avoid reusing names for different elements, suchProcessSales()And namediProcessSales.
• When naming an element, avoid homophone out-of-definition words (such as write and right) to avoid confusion during code check.
• 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.
• Avoid using printed tags to identify data types, such$Represents a string or%Represents an integer.

Note

Software Documents exist in two forms: external and internal. External documents (such as specifications, help files, and design documents) are maintained outside the source code. Internal documents are composed of comments written by developers in the source code during development.

The availability of external documents is not considered. The source code list should be independent because the hard copy document may be put in the wrong place. External documents should consist of specifications, design documents, change requests, error history records, and encoding standards used.

One difficulty of the internal software documentation is to ensure that the comments are maintained and updated at the same time as the source code. Although correct annotation of source code is useless at runtime, It is invaluable to developers who must maintain extremely complex or troublesome software snippets.

The following are recommended comments:

• If C # is used for development, use the XML document function. For more information, see the XML document.
• When you modify the code, always keep the comments around the code up-to-date.
• 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.
• Avoid adding comments at the end of the code line. comments at the end of the line make the code harder 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.
• Avoid messy comments, such as a whole planet number. Instead, empty comments should be separated from the code.
• Avoid adding a printed box around the block comment. This may look pretty, but it is difficult to maintain.
• Remove all temporary or irrelevant comments before deployment to avoid confusion during future maintenance work.
• 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.
• Use complete sentences when writing comments. Comments should clarify the code without adding meaning.
• 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.
• Avoid unnecessary or inappropriate comments, such as humorous and non-main comments.
• Use annotations to explain the intent of the Code. They should not be used as online translation of code.
• Comment out nothing obvious in the code.
• To prevent repeated problems, the code for error fixes and solutions always uses annotations, especially in the team environment.
• Use comments for codes composed of loops and logical branches. These are the main aspects to help source code readers.
• Throughout the application, comments are constructed using a unified style with consistent punctuation and structure.
• Separate comments from comments with comments in blank spaces. When you view comments without a color prompt, this will make the comments obvious and easy to find.

Format

Formatting makes the logic structure of the code very obvious. It takes time to make sure that the source code is formatted in a consistent logic, which is helpful for you and other developers who must decrypt the source code.

The following are recommended formatting methods.

• Create a standard indent size (such as four spaces) and use this standard consistently. Align the code section with the specified indentation.
• Use the monotype font when releasing the hard copy version of the source code.
• Align the Left and Right brackets vertically at the positions of the brackets, such:

  for (i = 0; i < 100; i++){   ...}

  You can also use the skewed style, that is, the left parenthesis appears at the end of the row, and the right parenthesis appears at the beginning of the row, such:

  for (i = 0; i < 100; i++){   ...}

  Regardless of the selected style, use that style throughout the source code.

• Indent the code along the logical structure line. Without indentation, the Code becomes hard to understand, such:

  If ... ThenIf ... Then...ElseEnd IfElse...End If

  Indent code generates code that is easier to read, such:

  If ... Then   If ... Then   ...   Else   ...   End IfElse...End If

• Create the maximum line length for comments and code to avoid having to scroll through the source code editor and provide a neat hard copy representation.
• Spaces are used before and after most operators. In this case, the intent of the Code is not changed. However, the pointer representation used in C ++ is an exception.
• Use blank space to provide structure clues for source code. This will create code segments to help readers understand the logical segments of the software.
• When a row is divided into several rows, the concatenation operator is placed at the end of each row rather than the beginning, clearly indicating that the rows without the end are incomplete.
• If appropriate, avoid placing more than one statement on each row. The exception is a loop in C, C ++, C #, or JScript, suchfor (i = 0; i < 100; i++).
• Standard tag and attribute formats are created when HTML is compiled. For example, all tags are in upper case or all attributes are in lower case. Another method is to adhere to the XHTML specification to ensure that all HTML documents are valid. Although the file size needs to be compromised when creating a web page, attribute values and ending tags with quotation marks should be used for easy maintenance.
• When writing SQL statements, all keywords are capitalized, and database elements (such as tables, columns, and views) are case-insensitive.
• Logically divide source code between physical files.
• Place each major SQL clause on different rows, which makes it easier to read and edit statements, for example:

  SELECT FirstName, LastNameFROM CustomersWHERE State = 'WA'

• Divides large complex code sections into small and easy-to-understand modules.

 

C #1.2 and 2.0 language specifications:

\ Microsoft Visual Studio 8 \ Vc # \ specifications \ 2052 installation directory in vs2005

Contains two files, corresponding to the 1.2 and 2.0 language specifications of C #. I believe it is helpful for anyone who wants to know C #.