However in this instance I’m working with a large legacy codebase. Even with the best intentions people won’t stick to a convention unless it gets enforced, and based on the amount of code that doesn’t comply it isn’t very simple to start enforcing the standard.

The only solution I could really see was to swallow the pain and go and reformat all of the existing code, then start enforcing analysis on the projects that have been updated.

I don’t think this would have even been possible if it hadn’t been for Resharper 5 and the StyleCop for Resharper plugin. I’ve become massively more productive since using Resharper a few weeks back and in this instance it’s been simply awesome.

Code Cleanup

Once Resharper has been configured with the StyleCop plugin so all coding style conventions are set up, you can run the code cleanup feature against a file or folder (Ctrl-Shift-Alt-F) which will reformat all existing code based on the configured rules. In my case this will typically reduce a file from around 300 violations to about 8. You can set up a profile to control exactly what does or does not get changed as part of this process.

Cycle through code issues (F12)

The next most useful feature is that StyleCop violations are treated as code issues by ReSharper. Hitting F12 repeatedly within a code file will jump to the next issue making it very simple to navigate around all violations and clean them up.

Violation highlighting within editor

The plugin will also highlight any style violation as you code, and provide tooltips and messages in the status bar to indicate what the violation was.

It will still take a while to finish updating the existing codebase, but I’m not even sure it would be feasible to attempt this without these tools.

I had heard a little about document databases being an alternative to relational databases (a slightly alien idea) but hadn’t got around to much research. In particular the session was looking at how to use CouchDB. The design goals are more based around assuming that individual nodes will fail, and having a lightweight, multiple-master setup with changes replicating across nodes.

From the introduction (which I recommend you read)… A CouchDB document is an object that consists of named fields. Field values may be strings, numbers, dates, or even ordered lists and associative maps. A CouchDB database is a flat collection of these documents. Each document is identified by a unique ID.

Unfortunately the session didn’t really cover how to apply this concept to a real-world scenario and how to perform useful queries against the data. However it was definately enough to encourage some reading around the subject – I think it’s important to understand the kind of problems where this could be a viable and better solution.