Thursday, September 23, 2010

StyleCop for ReSharper

Last night the UK ALM user group was fantastic. I really enjoyed it and we had good discussions going. So thanks to Stuart Preston for setting it up and thanks to the speakers, Karel Deman from Avanade for a great talk and Howard van Rooijen.

Which leads me to why I started to write this post. Howard demoed a tool he built called StyleCop for Resharper.

Now if you've never heard of ReSharper - shame on you, then you can search my blog or the web for info on it. If you've never heard of StyleCop then again search the web or read this post that should give you a quick overview of what StyleCop is designed to address:

Just quickly; StyleCop is a code style analysis tool. It at compile time will inspect your code against a pre-determined set of rules to determine whether your code complies with your companies coding style implicitly. The problem with it is it only tells you what is wrong with your code when you compile. And in order to get a list of "failures" you have to look at the warning tab in the 'Errors' window in Visual Studio.

When you install StyleCop: you get the option to install MSBuild targets that you can call during your automated build process. I haven't yet tried this but I will. As what you can do is fail the build if a developer has not complied to your companies codeing style.

Don't confuse StyleCop with FxCop or (Code Analysis) they are very different. Code Analysis inspects your assemblies post compilation for good practices in terms of how you have built your solution, i.e. implementing IDisposable when consumed types support it. Proper use of localization and best practice use of the .NET class libraries.

StyleCop for ReSharper is a ReSharper plugin (yes ReSharper supports plugins even though ReSharper is itself a VS plugin). What it does is it works like ReSharper, so as you type, it will inspect your code and tell you whether you are breaching StyleCop rules for that project. And as per ReSharper style, of hitting Alt+Enter, it gives you corrective options to fix your code for you!

I like it alot. I think it really is a great tool. Combined with the StyleCop build targets I think this can work well in a team environment. As to configuring your projects for StyleCop use, StyleCop creates a file in each project directory that it reads. It doesn't work like Code Analysis, where the settings are baked into the .proj file. So I'm thinking maybe include that file in Source Control so each dev machine doesn't have to configure their machine everytime a new environment is spun up or a new project is added to the solution.

Check it out here:


Unknown said...

As a ReSharper user and someone who is slightly OCD I love StyleCop and the ReSharper plugin.

One thing to be wary of though is when you import the styles it will over write any existing styles you have setup. I don't care what anyone says but usings do not belong inside the namespace! Thanks goodness you can turn rules off.

One thing I have done in one of my previous project was to get the build to break if style rules were broken. Then it didn't matter if someone else in the team was not using StyleCop it wouldn't get through the CI server.

Simon Hart said...

Mr Bronumski,

I'm not sure about the usings. I kind of thought initially that it was weird but now I'm quite liking it. It would be good if StyleCop for ReSharper work together as when you import usings using the normal ALT + ENT, ReSharper will stick them at the top of the file. The StyleCop will moan that they belong within the namespace.
The other thing I find annoying - this is a StyleCop thing, why can't I create rules at the solution level. It doesn't make sense to do this at the project level. Also adding configuration data to the project or solution would be better not a separate file on the file system. Have you tried adding the StyleCop rules to source control so it works well in a team environment?

Hows your new job?


Unknown said...

The StyleCop rules are inherited by folder structure. If you have all your projects in one folder then you can put the Settings.StyleCop file in there. In the past I have put all my test assemblies in a sub folder called tests which has it's own over riding set of rules which are more lenient.

The job is going well thanks, Cambridge is pretty interesting too.