Code review Tool StyleCop

"Code review" or "Code Review", this is a process that, when the developer writes the code, needs someone else to Review his code, which is an effective way to find bugs. As a result, we can examine the code's style, logic, ideas ..., identify problems, and improve the code. This is the best time to code refactoring, code resizing, code modification, because this is the time the code was just baked. So, code review is one of the most important aspects of coding implementation.

For a long time, code review needs to have some useful tools to support it, so that we can make it easier and more efficient to conduct code review.

StyleCop is the Code Review tool, which does not only check the code format, but rather the coding specifications, including naming and commenting. StyleCop can help you carry out this activity more easily. StyleCop now contains 200 or so best practices rules, which are consistent with the default code formatting rules in Visual Studio 2005 and Visual Studio 2008. It checks our source code according to the best practices of the predefined C # code format, and gives incorrect hints that do not conform to the coding style. This is similar to Microsoft's other code-checking tool, FxCop, but FxCop is checking DLLs (compiled binaries), so FxCop is for situations where new projects are being used through continuous integration tools. That is, FXCOP is project-level, and StyleCop is code-level, which is more appropriate for programmers to use during programming.

The rules for STYLECOP inspection include:

• Layouts (layout of elements, statements, expressions, and query clauses)
• Brackets position (Placement of curly brackets, parenthesis, square brackets, etc)
• Spaces (Spacing around keywords and operator symbols)
• Line spacing (line spacing)
• Parameter position (Placement of method parameters within method declarations or method calls)
• Element standard arrangement (ordering of elements within a class)
• Note Format (formatting of documentation within element headers and file headers)
• Named (Naming of elements, fields and variables)
• Built-in type usage (use of the built-in types)
• Access modifier usage (use of access modifiers)
• File contents (allowed contents of files)
• Debugging texts (Debugging text)

Common rules

Basis

Invalid spacing around the comma: ', ' After you need to add a space (a few does not matter)

Invalid spacing around the opening curly bracket: ' {' Before you need to add a space (just one, otherwise it will be reported ' the code contains multiple spaces in a row. Only one space is needed ')

Invalid spacing around the closing curly bracket: '} ' preceded by a space (IBID.)

All using directives must is placed inside of the namespace:using directive needs to be moved into the namespace

For example:

Using System; Using System.Text;
Namespace Stylecopdemo {public       class person       {       }}//should be Namespace Stylecopdemo {      using System;      Using System.Text;
     Public Class person      {      }}

I'm a little dizzy, too! But there is an article http://blogs.msdn.com/b/abhinaba/archive/2006/08/21/709051.aspx that explains the benefits of doing so!

Adjacent elements must is separated by a blank line: the adjacent elements must be separated by spaces, such as between a using namespace and namespace.

An opening curly bracket must not being followed by a blank line: ' {' The row below is not allowed to be blank

A closing curly bracket must not being preceded by a blank line: '} ' above line is not allowed to be blank

Using directives must is sorted alphabetically by the Namespaces:using statement must be sorted alphabetically (in order)

The code must not contain multiple blank lines in a row: Multiple lines in a row are not allowed in a line.

Error:

Correct for:

Document specification:

The class must has a documentation header: The defined classes must contain the file header flag '//' and the content description is preferably with a space (a bit perverted), or it may be reported ' the documentation text Within the summary tag does not contain any whitespace between words, indicating that it most likely does not follow a pro Per grammatical structure required for documentation text ', e.g.:

    <summary>///user basic information///     </summary> public    class person     {     }

The file has a no header, the header Xml is invalid, or the header isn't located at the top of the file:

Need to add at the beginning of the file:

-------------------------------------------------------//    <copyright file= "Person.cs" company= " MyCompany ">//             Copyright MyCompany. All rights reserved.    </copyright>//-------------------------------------------------------

Note the indentation format.

A C # document may be contain a single class at the root level unless all of the classes is partial and is of the same Type: "Guess" C # documents can generally contain only a description of a class. Unless the classes are of the partial type or are of the same type. This error typically has several different types of classes in a *.cs file.

Function Specification:

The method must has an access modifier: Methods require access modifiers (public private protected).

The method must has a documentation header: Methods must be documented to start with '///'.

The '///' specification requires:

Content inside the tag is not allowed to be empty. The content is best separated by a space otherwise will be reported ' the documentation text within the summary tag does not contain any whitespace between words, indicating tha T it most likely does is follow a proper grammatical structure required for documentation text ';

Instance:

Field Specification:

The field must has an access modifier: The field must have modifiers

Variable names must start with a lower-case letter: The name of the field must be the beginning of the lowercase

The field must has a documentation header: The field must have a document description that starts with//

Some programmers prefer to name fields with _, but StyleCop is not recommended. (Field names must not start with an underscore)

StyleCop is placed in http://stylecop.codeplex.com/, the latest version is released on July 5, 2012 4.7.44 version. More information can be found on the blog:http://blogs.msdn.com/sourceanalysis of the StyleCop development team

STYLECOP provides a simple and efficient way to check the code-writing style of a project. StyleCop can run in multiple ways, can be run in the IDE of Visual Studio in a plug-in manner, can be run as an MSBuild task, can be consolidated into the program build process, or run as a command line, and can be checked against one or more code files.

STYLECOP command-line use method:

usage:stylecopcmd [Options] [path]

Options:   -a         Process All source files found under the start P Ath (default)   -cs {file} Analyze the specified file.   -f         Perform A full analyze (ignore cached results)  & nbsp -u         do not write results cache files.    o {file}  Apply The given StyleCop options file to all projects and files   -l {file}  Save violation report at the given location. If omitted, saves               Stylecopviolations.xml in the current directory.   -P {path}  attempts to discover StyleCop AddIn modules under the given      &NB sp;        path. This flag is specified multiple times to search under               multiple Paths   -i         Ignore the default StyleCop AddIn Path under the all users\applica tion Data folder

Conditional compilation Flags:-define:flag1; FLAG2; FLAG3

Path:specifies the path to begin search for source files. If This is omitted, uses the current directory as the start path.

CodeProject has an article detailing how StyleCop is used C # Code reviews using stylecop–detailed article

Code review Tool StyleCop