Creating a custom dictionary for code analysis in VS2008

There seems to be a few posts out there asking where to put a custom dictionary to be used by FxCop (code analysis). In Visual Studio 2008, you can add a dictionary xml file to the solution and then tell the solution to use this as the dictionary for FxCop. Here's how.

Create your dictionary file
Add a new XML file to your project or solution and call it what you want. It doesn't need to be called CustomDictionary.xml.
The dictionary file must follow the correct schema, but unfortunately, there does not appear to be an .xsd schema file available (that I can find). As a starting point, copy the XML from the CustomDictionary.xml that comes with FxCop which is in the default FxCop install directory which on my machine is C:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\CustomDictionary.xml. You can then edit this file to include your own words. However, the schema is pretty simple:


Making FxCop use your dictionary
In the properties for the XML file you've created (right-click, properties), change the Build Action to 'CodeAnalysisDictionary'.
Recompile your project and FxCop should no longer complain about those words. If you examine the build output window, Visual Studio makes a call to FxCop.exe with a whole load of parameters. Setting the build action property of the xml file to CodeAnalysisDictionary, makes VS include the switch /dictionary:"" to the FxCop command.
You can also just amened the CustomDictionaryl.xml file in the FxCop default installation directory but this obviously only takes effect on that machine. I like being able to check this dictionary file into source control so that other team members can benefit from it and this also includes the build server.

Reusing the dictionary across assemblies
Another common situation is that you have more than one assembly and you want to share the same dictionary across them. One way of doing this is to add your dictionary file to the solution rather than a specific project. Then, add an existing item to your project, browse to the dictionary file in your solution, and select add as link. This add the dictionary file to your project and makes the link act like a shortcut to the dictionary file in your solution. This means you only physically create one dictionary file which is then easily shared across all your assemblies. Remember, you must still set the build action property on the link file in order for it to be recognised as a code analysis dictionary.
Note: You don't actually need to add the dictionary.xml file to the solution, but it obviously must be checked into your source control system and it should be referenced relatively, not absolutely.

The reason
In most projects I've seen, the code analysis rule CA1704 - Identifiers should be spelled correctly is all too easily ignored by adding a rule to the global suppression file. Personally, I don't like this because I think the global suppression file should not be used as a custom dictionary, especially when there is an alternative. The custom dictionary method is much more portable across projects and it preserves the separation of spelling against genuine code analysis errors.

Standup meetings: Keeping them useful

Every morning, we religiously hold a stand-up meeting to share information around the team - or at least, that is what's meant to happen. Over time, I've noticed that the whole idea of the meeting has been lost and people now attend the meeting because that's what they did yesterday and so it will go on until someone tells them to stop. The stand-up meeting is a technique taken from the Extreme Programming model and I believe it works effectively if you use it correctly.

A stand-up meeting every morning is used to communicate problems, solutions, and promote team focus.

So what does this mean? It means, you have to come to the meeting having prepared a synopsis of what you achieved yesterday focusing on the problems and solutions only. Don't talk about anything else. We only want to hear successes or failures and not all about your daily churn. Remember the audience that you are talking to - developers, testers, PMs, BAs, etc. They all have different interests but as a whole, they all must come together to ensure communication is effective across the team. This is the whole point of the meeting and everyone who speaks should bear this in mind and focus their content to suit the audience.

As a reference, here are some things I believe are not worth mentioning:

• Daily churn - by this I mean we don't want to hear that you fixed a few bugs, added a comment to the order class and corrected a few spelling errors. This is not helpful information and doesn't affect anyone else apart from you. If you do fix a few bugs, say what they were and why they will help other people.
  
• How you are tracking against your estimates is not productive on a daily basis because it's too granular. Project teams should also hold a weekly meeting that is more appropriate for this type of information. By all means highlight glaring errors in estimates, but don't talk about why you ran over by an hour on your last story card.
  
• Anything that is implementation specific - remember your audience, save geek-speak for developers.
  
• Any problems you are having that are not related directly to the project you are working on.

Typical things that I'd be interested to hear at the meeting are:

• Solutions and successes. For example, we've worked out a more efficient way of loading information from the database. Or we have changed the structure of the build file making it easier to maintain and it has reduced the build time. People want to hear about what you've been doing and if anything you have done can help them in the future.
  
• Problems - this means areas of the system that are causing longer development times or are very difficult to maintain. If you don't understand what or how you are meant to do something, raise this and identify someone who can help. If you sit on your own and never mention your problems, no one will know to offer help.
  
• Milestones or notable achievements - everyone likes to celebrate.
  

If you have nothing worth saying, don't say anything. You are not required to say anything but you should always attend the meeting to hear what other people have to say. I bet that if you were to ask a team to repeat what someone said in the stand up meeting yesterday, they would not remember unless it was notable. No one wants to remember useless or boring information but we are "programmed" to remember anomalies so focus your information on notable items.

Finally, remember the rationale behind the meeting and why stand-up meetings are part of the XP methodology. As a team, we want to be continuously improving and each member of the team should be making suggestions to ensure this happens. The stand-up meeting is a forum for everyone to discuss their daily findings and making sure that, as a team, we solve those problems. Also remember that a stand-up meeting is not an excuse to stop talking during the rest of the day. It's more likely that you will talk to people in a similar role during the day and this should always continue, but use the stand-up meetings to bring the roles together and to form a team that communicates information effectively.

Team Foundation Sidekicks V2 Released

Attrice Corporation released Sidekicks V2 on 7th January.

The version 2.0 of Team Foundation Sidekicks application provides all features available in previously released version 1.3.3, as well as new Code Review Sidekick. Significant number of bug fixes was also incorporated in that release; in addition, Team Foundation Sidekicks application now supports Team Foundation Server 2008.

This release also deprecates Team Foundation Sidekick Visual Studio add-in; all features previously available in add-in are now part of Visual Studio Integration Package (both for VS 2005 and 2008) which is in turn part of Team Foundation Sidekicks 2.0; new Code Review Sidekick is available as part of Visual Studio package as well.

Team Foundation Sidekicks application provides convenient GUI for a wide range of administrative and advanced TFS version control tasks. The version 2.0 stand-alone application includes Workspace Sidekick, Status Sidekick, History Sidekick, Label Sidekick, Shelveset Sidekick and new Code Review Sidekick. Team Foundation Sidekicks integration package for Visual Studio 2005/2008 includes Code Review Sidekick, source control items search, dynamic history and build types editing features.

Download from here