Welcome to MSDN Blogs Sign in | Join | Help

Clearing up Confusion

There has been some confusion and a few mixed messages coming out of Microsoft since the release of StyleCop, most notably around extensibility support for the tool, and licensing. We've gotten a lot of great feedback from the community, and in the last few weeks there have been some good discussions between various teams internally about how to position this tool, and how to best support extensibility.

Brian Harry, a Technical Fellow leading the VS TFS team, has recently written a great blog post explaining the context of these discussions and the decisions that have been made. You can read it here: http://blogs.msdn.com/bharry/archive/2008/07/19/clearing-up-confusion.aspx.

To summarize:

  • StyleCop is not part of the VS Code Analysis suite, and in fact has been developed outside of the VS team. It should be viewed as a complementary tool which focuses on code style and consistency. To help clear up this confusion, we are retiring the "Source Analysis" name and will be referring to the tool from now on as StyleCop, which is the original name of the tool!
  • We are planning to release an update which will introduce the naming change, and fix bugs that have been discovered by the community after the original release. This release will also include a handful of new rules which did not make it into the first release, and will incorporate some other great suggestions from the community.
  • We will be releasing a small SDK for the tool, describing the extensibility interface used to create custom rules, and explaining how to plug the tool into command-line based build tools.
  • We will be releasing documentation describing all of the default rules.

I would like to personally extend a big thank you to everyone who has taken the time to give us feedback about this tool. It's been very valuable and very much appreciated. A big thank you also goes out to Brian and others in the VS team who have been working hard to solve the issues around this tool.

We will spend the next couple of weeks getting the next version of the tool ready to ship, and getting all of the documentation ready to publish, and we'll get it out to you as quickly as we can!

Thank you!

 

Posted by jasonall | 4 Comments

A Brief History Of C# Style

A number of astute developers have noted that the C# code style enforced by Microsoft StyleCop differs in some ways from the style typically seen in sample code coming from the Microsoft Developer Division. For example, the very fine book Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams includes many code samples which use a different style, and this style is briefly described in an appendix in the back of the book.

In fact, the differences between the "StyleCop style" and the "Framework Design Guidelines style" are relatively minor. One of the biggest differences is that the framework style prefixes private and internal fields with an underscore, while StyleCop style omits the underscore and instead prefixes all class members with this.

The reason for the differences between the two styles is largely historical. The team that developed the first version of the .Net CLR consisted almost entirely of C++ developers. Remember, at this time no-one had ever heard of C# and in fact the language only existed on paper. When the original CLR was stable enough for internal use, people from the CLR team began writing test and sample code in the new C# language, mainly to test the CLR itself. Being C++ developers, these people naturally wrote their first C# code in a style that very much resembled C++, with liberal use of the m_ prefix, very little whitespace or comments, short, cryptic variable names, lots of Hungarian notation, etc.

Soon after this, an offshoot of the CLR team began writing the first version of the .Net Framework. Most of this code was written in C#. This was the first production C# code written anywhere in the world! Again, the team chose a coding style that mostly resembled C++. Over time this style has changed slightly, but the Framework team still uses this style for its internal C# code, as well as sample C# code provided to customers and partners.

After the first version of the .Net Framework was released, many other teams within Microsoft began writing new code in C#. Some of the biggest early adopters were, naturally, the Office team and the Windows team. Within a couple of years, almost every product group at Microsoft was writing at least some percentage of its code in C#. The architects and managers in these teams (being architects and managers) each took the time to come up with their own, individual style guidelines for the new C# language. In some places these style guidelines differed wildly according to the whims and fancies of the leaders of these teams. However, over time some C# style trends began to form, and these trends did not always follow the original style used by the Framework team. C# style had begun to evolve.

A short time after this, a brilliant young developer at Microsoft (ok, it was me) decided to take it upon himself to write a little tool which could detect variances from the C# style used within his team. StyleCop was born. Over the next few years, we gathered up all of the C# style guidelines we could find from the various teams within Microsoft, and picked out all of best practices which were common to these styles. These formed the first set of StyleCop rules. One of the earliest rules that came out of this effort was the use of the this prefix to call out class members, and the removal of any underscore prefixes from field names. C# style had officially grown apart from its old C++ tribe.

Development on StyleCop continued on and off for the next five or six years, and over this time many new rules were introduced. As you might expect, many wars were fought over the nature of these rules, and much blood was shed. In the end, decisions about StyleCop rules always came down to the following:

  1. What are most teams doing already?
  2. Which option is the most readable (highly subjective)?
  3. Which option will be the easiest to maintain over time?

StyleCop rules tend to encourage whitespace and openness in the code, as well as lots of comments and documentation. The rules also encourage developers to be explicit about what they are doing, and to minimize the need for assumption or guesswork on the part of the reader.

Today, StyleCop is very widely used within Microsoft, although it is still not an official, mandated tool internally. The .Net Framework team still writes code and samples using the original style derived from C++, and there are still some teams that have chosen to go their own way (and still some architects and managers with big egos). However, that is happening less and less internally, as more and more teams adopt the tool.

Now we have continued the evolution by releasing StyleCop to the world!

Thanks.

Posted by jasonall | 30 Comments

StyleCop Build Integration

The following article describes how to integrate StyleCop into the build, so that the tool will run automatically whenever a build is performed:

 http://blogs.msdn.com/sourceanalysis/pages/source-analysis-msbuild-integration.aspx

Posted by jasonall | 0 Comments
Filed under:

Future Plans

Since the release of StyleCop, many people have pointed out that a number of the rules enforced by the tool could be automatically corrected by the tool, without requiring the developer to do the corrections manually.

As you might imagine, this functionality is also highly desired by the developers using StyleCop within Microsoft, and this will be the main focus of the next major release of the tool.

Early stages of development have begun on this effort, but at this time there is no annoucement about a potential release date. Expect this to show up at some point in the future.

Posted by jasonall | 7 Comments

Announcing the release of Microsoft StyleCop

We are very excited to announce the release of a new developer tool from Microsoft, Source Analysis for C#. This tool is known internally within Microsoft as StyleCop, and has been used for many years now to help teams enforce a common set of best practices for layout, readability, maintainability, and documentation of C# source code.

StyleCop is similar in many ways to Microsoft Code Analysis (specifically FxCop), but there are some important distinctions. FxCop performs its analysis on compiled binaries, while StyleCop analyzes the source code directly. For this reason, FxCop focuses more on the design of the code, while StyleCop focuses on layout, readability and documentation. Most of that information is stripped away during the compilation process, and thus cannot be analyzed by FxCop.

The ultimate goal of StyleCop is to allow you to produce elegant, consistent code that your team members and others who view your code will find highly readable. In order to accomplish this, StyleCop does not allow its rules to be very configurable. StyleCop takes a one-size-fits-all approach to code style, layout, and readability rules. It is highly likely that you will not agree with all of the rules and may even find some of the rules annoying at first! However, the majority of teams using this tool within Microsoft have found that after a short adjustment period, they came to appreciate the rules enforced by StyleCop, and even began to find it difficult to read code not written in this style. 

StyleCop comes with a set of default rules analyzers covering approximately 200 best practice rules. These rules are full compatible with the default layout settings in Visual Studio 2005 and Visual Studio 2008.

Specifically, these rules cover the following, in no particular order:

  • Layout of elements, statements, expressions, and query clauses
  • Placement of curly brackets, parenthesis, square brackets, etc
  • Spacing around keywords and operator symbols
  • Line spacing
  • Placement of method parameters within method declarations or method calls
  • Standard ordering of elements within a class
  • Formatting of documentation within element headers and file headers
  • Naming of elements, fields and variables
  • Use of the built-in types
  • Use of access modifiers
  • Allowed contents of files
  • Debugging text

After installation, StyleCop can be run from within the Visual Studio IDE, and can also be integrated into MSBuild-based command line builds.

StyleCop can be downloaded here: https://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=sourceanalysis. We're looking forward to hearing your feedback!

 

Posted by jasonall | 89 Comments
 
Page view tracker