Style Cop and VS Defaults

I have been playing with Microsoft new(ish) code analysis tool StyleCop over the last couple of nights (god forbid I use it on our work code base!). Its a pretty cool tool in the same vein as FXCop but with more of a focus on general code layout etc. In this regard its pretty cool. It gives you warnings for when rules are broken & it integrates into VS quite nicely. Unfortunately there is no clean way of integrating it into my NAnt scripts as there is no exe to call. Apparently you can put it into your MSBuild scripts, but that’s kinda weak that they have not provided an exe for other means… any who…

It also highlights the fact that VS default templates do not adhere to the StyleCop rules. If you run StyleCop over a standard code base you will see a bunch of warnings straight off the bat. Firstly there are no file headers on any standard C# file.

An XML type header need to be placed in every file. This to me stinks of C headers… are we not a bit past this? Is this really required? There are copyrights on the project in the assembly file, do we need the clutter on every single file (and repeated in the AssemblyInfo.cs twice)?

Well if you do then feel free to add a header similar to:

//
// Copyright (c) 2008 All Right Reserved
//
// Rhys Campbell
// rhysc@fullstack.co.uk
// 2008-09-10
//

Contains assembly information.

It also points out the VS, by default, places the using statement on the outside of the namespace which the pigs don’t like!

Fortunately there is an easy fix to these and other default behaviours: Templates.

Visual Studio has configurable templates for the files it creates, so you can modify the standard output to what you want. These template reside as zip file in the C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplates\CSharp\ folders and are actuall cached near by in the ItemTemplatesCache folder. You can make your own personal templates and by default they hang out in C:\Users\Rhys Campbell\Documents\Visual Studio 2008\My Exported Templates\.

Say for example we wanted to trim the  StyleCop warnings of our projects down a bit then the above examples could be changed from

using System; 
using System.Collections.Generic; 
$if$ ($targetframeworkversion$ == 3.5)using System.Linq; 
$endif$using System.Text; 
namespace $rootnamespace$ 

class $safeitemrootname$ 
    { 
    } 

To something like :

//
// Copyright (c) 2008 All Right Reserved
//
// $username$
// $username$@fullstack.co.uk
// 2008-09-10
//

  

namespace $rootnamespace$ 

using System; 
public class $safeitemrootname$ 
    { 
    } 
}

To do this just crack open a new class, make the changes to the layout you want using template parameters in logical places (i.e. class, namespace, date etc) and File > Export to Template… *

You can select the namespaces required and even pick a pretty icon for your new template. This is particularly good if you use a bunch of standard classes (Tests, NHibernate, WCF all spring to mind) and it should speed things up nicely 🙂

To use you new template Just Add a new item to a project and under all the standard templates will be a “My Templates” section with your new tempate happily residing.

*If your Export to Template, like mine, is not there, go to Tools > Customise and drag the command from the depths of the hidden file options on to the file menu drop down (i.e. Commands > Categories=File > Command = Export Template..)

Build scripts

I will be honest; I am pretty much a rookie at build scripts. I know some guys out there have weird and wonderful super complex complex NAnt, MSbuild, *ake files that do everything in including there dirty washing.
Well over the last year I have usually had a build script lying around that was kinda “just there”, more for assurance that what i was doing could be easily hooked in to a CI scenario. However I have been using the build script local over VS lately and am finding it pretty good. It certainly is a lot faster just to build the soln. I can also :

  • control what gets built
  • what tests are run
  • what code analysis gets done
  • if i need a distribution zip etc

all by clicking on a different bat file.
All of my tasks are in my NAnt file and each bat file just points to a different task.
I have a quick build (no test or code analysis), a standard build (build, run all unit tests and code analysis) and a deploy (standard plus zip the required files for a deploy).
Any solution bigger than a scratch pad can really benefit form a build script. The best thing is, if you are like me and many of your solutions have the same general structure, once you are happy with your defaults then you just need to change one or two parameters in the script for your different solutions.
If you are not using a local build script i would highly recommend it. I am just disappointed I have not been using it more in the past.

Gray hairs and coronaries …

Refactoring fundamentals of a rather large stack ca be daunting… I gave it a go over the weekend, modifying hundreds of files and tens of thousands of lines of code and, to be honest, I thought I had done a pretty good job doing so.
Monday morning comes around and there where some Small build issues (csproj.user are not in the a build outside of VS) but easily fix.
The really problem was when we started to do complex interactions… the app died…

Oh sh1t…. I’m fired..

Well maybe not fired just roll back to Friday and I have wasted a weekend.
Long story short… don’t leave on Nhibernate logging… it kills your app.
Commenting out log4net returned everything to normal, now we just need to log the correct things (ie not every NHibernate interaction!)

Better Know a Framework!

In the vein of the DNR guys:

ImmutableAttribute to continuously check that a class or a structure is immutable.

PureAttribute to continuously check that a method is pure, i.e it doesn’t provoke any side effect by modifying some fields states.

default C# Keyword in Generic Code. Will return null for reference types and zero for numeric value types

These are things that i haven’t used in the past when i should have, but not any more! 🙂